Skip to main content

Show Me The Money

Written by Marcos Ferrer on . Posted in Articles.

Last month we posed a quiz, as we continue to build robust requirements for a National and Global Identity System. We “hid money” in this quiz, and now we’re going to try to find it! Here is the list of stakeholders we gave last month:

Citizens

Businesses

  • Banks
  • Credit Card Companies
  • On-Line Sellers
  • Airlines
  • Hotels
  • Disney (takes fingerprints, did you know?).
  • Retailers
  • More along the same lines….

Government

  • Law Enforcement
  • National Security
  • Immigration
  • Customs
  • Internal Revenue
  • Labor Department
  • Unemployment Agency
  • More along the same lines…
  1. What might be wrong with the above list? First – note that it is not only citizens with a stake, but all individuals. If you were being arrested, how would you feel if the police identified you improperly? If you are an illegal alien, you still need to work (and we need you). What is to be done? Second – what about non-business, non-government institutions? Are non-profits different? Are some organizations not even characterizable simply as non-profit? Third – identifying individuals, businesses, governments and other institutions may not be sufficient. Do all stakeholders have the same needs and goals? Are there categories based on identity “needs” more useful than the institutional ones we have chosen? How is local law enforcement different from homeland (I hate that word) security or immigration?
  2. What might it cost to ignore the errors/omissions/assumptions, if any? We know the answer to this, because existing ID systems have NOT identified and addressed all stakeholders and their needs. The cost is exactly the situation we have now – a world of rampant identity theft (1 in 20 may be affected each year), in which law enforcement is almost powerless, a world of unjust convictions and misuse of DNA evidence, a world of constant privacy violation with little or no recourse (the price of fame is constant media pecking, a disincentive to achievement).
  3. What concepts or categories might help with analyzing this list, regardless of any problems so far? Identity needs for criminal convictions are different from those for purchases, for charitable giving, attendance at private social events, and hiring a handyman, etc.
  4. If you, as a BA, can even begin to address such questions, what is your earning potential? I can only speak for myself – since realizing what I was capable of, and getting my CBAP so others would know too, my income is now well into six figures, and my ability to get work and promotions is vastly improved. How are you coming along?

FOR NEXT MONTH:

To reassure ourselves that we REALLY understand the stakeholders, we will try to list the “identity transactions” that might occur in society, and we will try to match these transactions to the kinds of stakeholders we are aware of so far (individuals, businesses, government, and other organizations).

 How many identity transactions can you think of, or how would you elicit such a list?

Potential answers will be discussed next month, and incorporated into the case study. The best reader response will be acknowledged next month (send a picture with your response!) and will undoubtedly receive a large raise in the near future, just for rising above the pack!

Defining Value to Prioritize Features

Written by Cynthia Low on . Posted in Articles. 1 Comment on Defining Value to Prioritize Features

Building The Right Thing

One problem with software development methods these days is that there are a lot of different ideas on the right way to build things, but we don’t have too much guidance on how to make sure we are building the right things. There is plenty of advice on the best techniques to develop quality software, but all of this guidance is based on the assumption that the team already knows what they are supposed to be building. When it comes to how to find that out, just about every methodology has the customer/stakeholder/product owner prioritize the features/use cases/user stories.

Great, but do our stakeholders always know a sure fire way to properly define what is the most important aspects of a product or system. Do they always have an objective understanding of whether the product or service should be created or updated in the first place? All too often, stakeholders don’t have a clear idea of how to determine if they are asking for the right thing, and the project team doesn’t necessarily help them.

So what does it mean to build the “right thing”? Well, one way to look at it is to understand:

  • What projects should the organization undertake? 
  • What features should be provided for those products or services? 
  • What order should features be delivered?

So how do project teams “do the right thing”? It comes down to the project team, including the stakeholders, working together to understand the organization’s definition of value, applying that definition to determine the value delivered by their projects, determining how the features contribute to the project’s value delivery, and prioritizing the features accordingly.

We’ll discuss each of those steps in turn. One thing to note that whenever I say project team, I include stakeholders in that grouping, and I use stakeholders interchangeably with customers, product owners, users, goal donors, and gold donors.

The Organization’s Definition of Value

Value is one of those words that, while easy to define, often means different things to different people, especially when used in the context of software development projects. The most appropriate dictionary based definition is: “relative worth, utility, or importance.” (http://www.merriam-webster.com/dictionary/values). When you consider this definition, it is easy to see why the definition of value will vary between different organizations. It just so happens that an organization’s strategy, as expressed by its strategic decision filters, provides a definition of value. Strategic decision filters basically provide simple rules to determine which activities create and support sustainable competitive advantage, and which activities detract from an organization’s maintaining its competitive advantage. Anything that creates and supports the organization’s sustainable competitive advantage inherently is valuable to the organization.

The Value Delivered by the Project

Once the project team understands what is valuable to an organization, they can establish a value model for the project, which provides the project team with a tool to repeatedly assess the value delivered by a project.

The value model has four key inputs:

  • Purpose. A statement about what problem the project is trying to solve, or for those optimists out there, the job that the project is trying to get done.
  • Considerations. All those aspects of the project that could impact the value produced by the project, but are either too difficult to quantify, or haven’t happened yet, such as risks, issues, assumptions, and constraints.
  • Cost. The financial resources required to undertake the project, including such things as the people working on the project, hardware, and software.
  • Benefits. The positive impact the project has on the organization. Benefits can be financial in nature, such as increased revenue or reduced costs; or non-financial, such as support for other initiatives, or improved customer satisfaction. It is a good practice for the project team to collaborate on the purpose of the project first and run that purpose through the organization’s strategic decision filters. If the project fits within those filters, the project team can then continue to understand the remaining inputs. If however, the purpose of the project does not pass the strategic decision filters, then work on the project should stop, as it will most likely not deliver any value to the organization. Of course, if the result of the effort to evaluate the project purpose against the strategic decision filters results in the question, “what strategic decision filters?” then the organization has some more fundamental work to do.

If the project is a strategic fit, the project team then collaboratively identifies the considerations, costs, and benefits of the project and crafts a model to determine the value delivered by a project. This model should be built in such a way that it can be quickly updated and analyzed throughout the life of the project as considerations change, costs are better understood, and the benefits produced become clearer. The advantage of this approach over the typical practice of developing a business case to justify the project and then never reviewing it again, is that the project team is able to determine if the project is on track to deliver the expected value, or if conditions have changed such that the project no longer makes sense to continue.

Feature Contribution to Value

Once the project team has a grasp on how the project adds value to the organization, they can start analyzing how the various features under consideration contribute to the overall project value delivery. This can be difficult because the size of feature that delivers discernable project value is often different than the level at which the project team is comfortable fully defining features. A solution to that problem is to group finely grained features into the smallest grouping that delivers value to the stakeholder. Mark Denne and Dr. Jane Cleland-Huang introduced this concept and called them Minimal Marketable Features (MMF) in their book Software By Numbers (http://www.softwarebynumbers.org/default.htm).

 Project teams can organize their features into MMF and then, through an understanding of the relative value of those MMF’s to the overall project, prioritize the features delivered by terms of relative value contributed to the project. This approach is especially effective when the project team is following an iterative approach to development, when subsets of the overall feature set included in a project are delivered on a regular basis. Ideally, project teams will find themselves in a situation where they are able to identify a financial value delivered by a feature, but this is the exception rather than the rule. More often than not, project teams have to express the value in relative terms compared to other features included in the project. Regardless of the measure used, whether it be hard dollars, or a unit of less relative weighting, the key is for project teams to have some understanding, objective or subjective, of the value each feature contributes to the overall project and use that value as the basis for prioritization decisions.

Really Analyzing the Business

What I have just described is business analysis at its finest. It goes beyond simply “gathering” requirements to truly developing an understanding of the business, the problem that needs to be solved, and the benefits of the solution to the overall organization. This approach requires a great deal of collaboration between all involved in a project, especially business analysts, who should have the appropriate skill sets to facilitate the creation and revision of the value model, and the application of that definition of value to the features included in the project. A business analyst who has these skill sets is truly setting themselves up as an invaluable person to their organization.

Kent McDonald

is a Business Systems Coach with Knowledge Bridge Partners and Partner in Accelinnova, http://www.knowledgebridgepartners.com. He has more than a decade of experience guiding successful projects and designing business solutions in a variety of industries including financial services, health insurance, performance marketing, human services, non profit, and automotive. His background includes delivering data-intensive and web-enabled application development projects that provide outstanding business value. He has coached client staff to help teams reach project goals more productively and effectively. Kent is a speaker, writer, and coach on project leadership, business analysis, and delivering business value through projects. He can be reached at [email protected]

The Business Analyst and Project Manager Rolled into One!

Written by Terry Longo on . Posted in Articles.

Terry Longo’s Monthly Blog

During two of the three recent Project Summit / Business Analysis World conferences, I had the privilege of moderating a roundtable discussion whose topic was “The Dual Role of Project Manager and Business Analyst: Is it Possible?” It is, of course, no surprise that it is not only possible, but very common. (In my informal polls of audiences at my presentations, it seems that roughly 10-30% of the people in the audience are playing both roles).

The underlying question of course is “Can it be done well, and what are the benefits, costs, and risks?” And, in light of our intensifying efforts to professionalize the business analyst role, this question is vital, for it has significant implications for the organization relative to:

  • Job definitions 
  • Career paths for people aspiring to or in PM- or BA-related roles 
  • The manner in which stakeholders engage with requirements teams and solutions teams 
  • The nature and rigor of the requirements-related language present in the organization’s culture 
  • The design of processes, policies, and tools underpinning PM and BA activities 
  • The practitioner’s ability to distinguish between requirements-related change and risk and project-related change and risk

As far as the factors that make it workable with acceptable results, the two I hear about most are: 

  1. Small projects 
  2. The absence of compliance-related documentation requirements. This is interesting, since being in a compliance environment demands so much in the way of documentation of project and requirements activities, that it can be overwhelming for one person.

The questions in my mind now are (a) if there are other factors in favor of the dual role assignment, what are they, and (b) if there are no advantages on larger projects, why are we (the collective we, of course) doing it to ourselves?

Much of the answer lies somewhere in the current recognition of the role of the Business Analysis Center of Excellence, a part of the charter of which would be to understand more deeply the dynamics of the dual role, and only support it where it is justifiable in terms of risks and benefits.

Without that risk/benefit view, it seems to be, well, risky.

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/section/pm_bus_analy.html or at [email protected]

The Thin Line Between SME and PM

Written by Cynthia Low on . Posted in Articles. 1 Comment on The Thin Line Between SME and PM

It isn’t uncommon for Subject Matter Experts (SME) to run or lead projects. In fact this tends to occur when the sponsor’s focus is on the conten, of the project. They often don’t really see the value of a separate PM role.

While it is vital to have a subject matter expert or analyst on a project, (as PMs should not be responsible for developing solutions) there are some subtle yet potentially costly risks associated with putting that individual in a dual SME/PM role.

It is human nature to focus our attention and efforts in our areas of expertise and, more often than not, this is what occurs. An SME is more likely to focus their attention on the details around the solution and to then go through the motions when it comes to the PM component of their role. This includes throwing together a project plan, because this is expected of the PM side of their role.

In my time, I have come across many SME built project plans and they contain some consistent findings. One is that the project plan always seems to end on the targeted project completion date, but the critical path cannot be calculated. This is usually because there are few if any dependencies built in. Instead the Start No Earlier Than (I call it the SNET) constraint is abused throughout the plan, obscuring the total slack.

So what? Well, while the solution may approximate perfection, the estimated time, effort and costs are unknown and likely based on a faulty work back plan. The project plan is simply window dressing, there simply to satisfy the sponsor and stakeholders’ need to see things appear to wrap up on time.

What results is often a project that overruns its scheduled time due to poor planning. Key resources, that may also cost dollars (IT resources or consultants), either disperse to other previously committed projects or must charge the extra time against the project, increasing the budget and lowering the return on investment.

In many cases this part of the job is severely neglected in favor of developing solutions. The other risk is that having an SME who is also responsible for the PM function is akin to having the fox watching the chicken coop. The PM role naturally provides the devil’s advocate to question the validity and assess the overall impact to the project’s success when change requests are introduced.

Scope creep cannot be properly managed without having an unbiased second opinion and a true assessment of the impact on the overall plan. This again leads to the perfect solution that will likely meet none of the requirements of the triple constraint. If getting to market on time is a key requirement, you need to have someone whose focus will remain on getting to market on time. SMEs are excellent at what they do which is why they perform this role. Their participation is vital to the project’s success. Excellence and perfection are the undying goals of a SME and rightly so. This is why they are at the table.

A PM’s role is to ensure that ALL of the objectives of the sponsor are being addressed, stakeholder expectations are managed, and that there is a high quality, regularly revisited plan in place along with the proper checkpoints and processes to address the unknown unknowns that tend to crop up at inopportune times.

Not all projects require a PM. As a rule of thumb, if the number of stakeholders and team members is small, the scope of the project is limited to one department (not an enterprise wide project) and time and cost is not an issue, you may be able to manage with a SME/PM. Once the scope of the project grows beyond this, your risks increase significantly unless you have a qualified and experienced project manager running your project.

The PM’s view of the project is much broader than the SME’s and project success means keeping your eye on all the moving parts of the project, including the solution.

Sean Best, PMP is a project management consultant and managing director of CRM Project Management Consulting. His 14+ years of project management experience includes work in the banking, payment processing, telecommunications and software industries. He can be reached at [email protected]

The Case for Establishing an Internal Business Analysis Certification

Written by Cynthia Low on . Posted in Articles. 1 Comment on The Case for Establishing an Internal Business Analysis Certification

With the growing importance being placed on professional certification like the Project Management Professional (PMP) and the Certified Business Analyst Professional (CBAP), setting up an internal business analysis training program, in partnership with an Endorsed Education Provider (EEP) of the International Institute of Business Analysis (IIBA) might make sense for many companies.

The result would be a designation that would combine the best practices of the business analysis profession with the specific organization’s corporate strategy, business domain model and project management lifecycle. This is possible through a single certification process established internally in an organization.

An internal certification program for business analysis should be a joint effort between a company’s training department and its established BA Center of Excellence.

Objectives of an Internal BA Certification Program

There are many goals to be achieved by establishing an internal BA certification program:

  • Raise the performance standards for business analysts within the company. 
  • Educate BA staff about proven best practices amongst the company’s various departments. 
  • Align industry standards with the company’s standard project management lifecycle and system development lifecycle methodologies. Thus, management doesn’t have to worry about their company’s BA staff utilizing analysis techniques and methodology standards that their company may not recognize. 
  • Additionally, such a BA certification would align IIBA best practices and methodology standards with the company-wide BA procedures and audit practices. 
  • Provide a training outlet within the company for BAs to gain PDUs (professional development units) with the IIBA (or other professional organizations) as well as CECs (continuing education credits) with academic institutions. This is accomplished by partnering with a vendor approved by the IIBA, which will ensure that the majority, if not all of a company’s BA staff, will receive the same quality training.

Training Vendor Partnership

Partnering with a training vendor is critical to the overall success of an internal certification program for the following reasons: 

  • BA staff from different departments will receive the same quality training and tools. 
  • BA staff will be seeking external training opportunities as a last resort. 
  • Most training vendors provide a discount for a group of class registrations from the same company. As an added measure of ROI (Return On Investment), partnering with a training vendor will save the company training costs.

Internal Certification Structure

An internal certification program should be structured with key educational design factors in mind: 

  • To be certified, candidates would be required to pass an examination with questions based on the core knowledge areas of business analysis as well as experience/scenario based short essays. This would be a single examination encompassing all the core knowledge areas that make up the BA profession, in addition to the company’s standard project management lifecycle and system development lifecycle methodologies. 
  • Candidates would be required to complete a minimum number of annual volunteering/activity hours with the company’s BA Center of Excellence and/or their local IIBA Chapter (in case only one exists.) 
  • Candidates would be required to complete a set number of courses (or be waived by passing knowledge/skills assessment for each course). An ideal outline of BA courses would include the following:
    Course Outline Mandatory for BA Career Levels
    1) Corporate Strategy and Business Domain  BA-1, BA-II
    2) Advanced Knowledge of the Business  BA-II, BA-III, Senior BA
    3) Introduction to Business Analysis  BA-I
    4) Overview of the Organizational  SDLC BA-I, BA-II (optional)
    5) System Design Concepts  BA-I, BA-II
    6) Essentials of Risk Management and Validation  BA-I, BA-II, BA-III
    7) Business Process Modeling  BA-I, BA-II, BA-III, Senior BA
    8) Business Requirements Elicitation and Management BA-I, BA-II, BA-III, Senior BA
    9) Advanced Business Analysis BA-III, Senior BA (optional)

  • Provide an outline of optional courses in business analysis for non-BA staff interested in business analysis or who perform occasional BA roles, such as project managers, developers and testers.

So you can see, establishing an internal BA certification would be of great benefit to many corporations and forward-thinking organizations, regardless of size. This would ensure that the organization has the near perfect talent pool of BA skills and knowledge from both industry-wide and internal corporate points of view. Thus, an organization’s BA staff can more realistically balance internal project weaknesses and strengths with external market threats and opportunities.

Youssif Ansara is an IT Business Consultant who has worked with various industries including oil and petrochemicals and health care insurance, as well as entrepreneurship in the education sector. He gained his expertise from his involvement with technical business analysis and human resource management, both in the United States and abroad. He is an avid advocate of usability testing in both the public and private sectors to ensure that their systems are widely accessible. He does this by conducting accessibility assessments and public speaking about Section 508 of the Rehabilitation Act as amended by the U.S. Congress in 1998 to ensure that electronic and information technology can be accessible to people with disabilities. Youssif Ansara, can be contacted at [email protected]

© Youssif Ansara, 2007