Skip to main content

Author: Mark A. Monteleone

As a Project Sponsor, What is Your Documentation Risk Tolerance?

To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question.  This article is a follow-up to the BATimes publication, “Verifying Requirements Documentation.”  As author of the article, I took special note of a readers comment on providing organizations a continuous process improvement model on composing a business requirements document (BRD).  The comment was:

“… I too found some things worth cutting and pasting into some training or checklist material. The post script was prophetic – the environment for BRD seems to be getting squeezed by those who find the whole process “too cumbersome” and not (lowercase) “agile enough”. I know of lots of orgs whose risk tolerance is so high that they could never see the ROI in it. I Think much of the great material here could be better digested by some organizations if one applied it as part of Continuous Process Improvement. As you find cause to question your BRD effectiveness, compare your process for creating brd documents to this model. While few organizations are willing to invest in all of this effort up front (and it can be appear to be oppressive), laying this out as the gold standard sets the bar for where you can go. When flaws are found or systems don’t meet expectations, the project closure efforts should certainly involve looking at the shortcomings, comparing to this list and considering what additional pieces should be included next time to avoid the flaws, increase acceptance, or implement a solution that’s more relevant to the customer….”  #Tony 2012-01-25 22:20
This comment caused me to pause and wonder if one could construct a BRD risk tolerance model based on the contents of the BRD.  In other words, what is the risk tolerance if only certain best practice components are included in the BRD?  And can the BRD risk tolerance be represented as a sliding scale.  The purpose of this article is to propose a risk tolerance model as a sliding scale based on what is included in the contents of the BRD.

What Makes a Project Sponsor Approve the Business Requirement Document?

Risk tolerance.   The project sponsor signs-off the business requirement document when the document matches or surpasses the risk tolerance of the sponsor.  Note risk tolerance is relative to the sponsor and changes depending on the risk of the project.  For example depending on the size of the company, a $10M project motivates the sponsor to have a much lower risk tolerance than a $10K project.  Project sponsors could cite several other reasons for variable risk tolerance such as project complexity, resources, etc.  The follow-up question and point of this article is:  Can portions of the BRD be equated to various levels of risk tolerance?

A Proposed Business Requirement Document Risk Tolerance Model

Below is a BRD Risk Tolerance model (Figure 1).  It depicts a cumulative risk tolerance incline starting from a high-risk tolerance (lower left corner) to a low-risk tolerance (upper right corner).  Supporting the risk incline are seven best practices for writing a BRD.  Under each best practice are key words describing the practice; for details see “Verifying Requirements Documentation” (1).  On top of each best practice is a cumulative risk tolerance percentage.  This percentage represents the cumulative risk the project sponsor assumes when BRD components are missing.  For example, a risk tolerance of 50% equates to signing-off a BRD with all the best practices above the percentage (data requirements, transitional requirements, and traceability) missing from the BRD.  Note that for every missing BRD component the probability of defects increases in the deliverable.

MarkAug22nd

Figure 1. Business Requirements Document Tolerance Risk Model

First a Note on Project Risk

Before reading the below examples, note the percentages on the model are the sponsor risk tolerance for a project equated to “allowed” missing BRD components.  As stated before, project risk depends on the characteristics of the project (i.e., size, complexity, cost/benefits, technology, resources, duration, etc.).  The point here is that the project risk may well influence the project sponsor on what is an acceptable BRD.   

BRD Risk Tolerance Model Examples

Below are examples of BRD risk tolerance using the model in Figure 1.      

  • A project sponsor may well be justified assuming a high-risk tolerance with the BRD missing various components for a project entailing a small modification to an existing system (i.e., the cost of the BRD should not exceed the benefit of the modification).  
  • A project sponsor could assume a low-risk tolerance missing any components in the BRD for a project providing a strategic new service for the business (i.e., product defects will have a major impact to the business).  
  • If a project sponsor decides to accept a BRD with only process improvement targets and functional requirements documented, the sponsor assumes a risk tolerance of 70% (i.e., still assuming considerable risk of defects in the product or service).
  • And so on up and down the risk tolerance incline.    

BRD Risk Tolerance Model Use

The business analyst can possibly use this model as a guide for management on the level of risk assumed when approving a BRD.  On almost every project, there is a question on how much to document in the BRD.  The answer lies within the range of the project sponsor’s BRD risk tolerance.  Using this model, the business analyst can associate the BRD components with levels of risk tolerance.  With this model plus the characteristics of the project, the project sponsor has enough information on the appropriate risk to assume. 

MarkAug22nd2

Can This Model Be Used on an Agile Project?

Agile projects do not generate a formal BRD.  User stories are the basis for iterative development.  However, the product owner (sponsor) needs to consider risk tolerance when reviewing the product backlog and during the retrospective prior to approving the product release.  Questions to consider:

  • Are process improvements targets addressed?
  • Are specific functional requirements present?  Are they being addressed in business value order?  Are dependencies considered?
  • Are nonfunctional requirements measured?
  • Are the business rules incorporated within the software decisions, access authorizations, and conditions?
  • Are data relationships and cardinalities present in the files?
  • If replacing a legacy system, are transitions planned?
  • Are the original scope features reflected in the user stories?  Can cost/benefits be linked to the deliverables? 

Summary

What is your opinion of the BRD Risk Tolerance model?  I invite your comments.  Perhaps you prefer a different component order or a different level of percentages on the Cumulative Risk Tolerance line.  If you are a project sponsor needing to know what best practices should be used in a BRD, see the article cited in the reference.   

References

  1. Monteleone, Mark (2012), “Verifying Requirement Documentation,”      

Don’t forget to leave your comments below.

Resistance as a Major Source for Requirements Risk

mm1This article recognizes resistance as a source for requirements risk. Business analysts recognized assumptions, constraints and dependencies as the major sources of requirements risk. However, in every analysis there is some level of resistance to change. This article reviews the three traditional sources of risk and makes the case for including resistance as an additional source.

What is risk?

Risk is an uncertain event that can have a positive (opportunity) or negative (threat) impact on an endeavor (1). In this context, the endeavor is developing requirements (elicitation, analysis, documenting, and validation), which may be a change to a process and/or software. The result of the development effort is a business requirement document that reflects a stakeholder consensus. Typically, the business analyst recognizes three major sources of risk in planning requirements development:

mm2• Assumptions – business conditions that if changed would affect the requirements or requirements development
• Constraints – conditions that restrict the development of requirements
• Dependencies – requirements that are dependent on other requirements

Change Equals Resistance

The business analyst is a change agent. In developing requirements, the business analyst is inherently involved with change. And, where there is change, there is resistance.

mm3• Resistance is a barrier encountered by the business analyst in developing requirements from stakeholders

Resistance comes in all forms and degrees. Stakeholders typically expressed resistance as a concern or a reservation. However, it may also be to an out-right objection. The key for resolution is for the business analyst to engage in a dialogue with the stakeholder that leads to the reasons behind the resistance (see Figure 1).

mm4
Given the above, the business analyst needs to recognize resistance as a major source of risk and manage it as in the other major risk sources. The business analyst needs to identify its possible occurrences, analyze its probability and impact, and develop a risk response. Note that risks that stem from resistance are threats. In this case, the business analyst needs to avoid, transfer, mitigate, or accept the threat (see Figure 2).
mm5

A Homestead Example

mm6Dick and Jane are a couple with a nice home and are business analysts for a large firm in a downtown business center. One day Dick and Jane decided to upgrade the single pane windows of their home. Being experienced business analysts, they first listed their major sources of risk (assumptions, constraints, and dependencies) and then prioritized their requirements.

  • Assumptions
    • Continue to live in the home for at least 20 years
    • Able to recover window upgrade cost if home is sold
    • Energy cost will continue to rise
    • Reliable contractor available
  • Constraints
    • Budget is $25K
  • Dependencies
    • Compatibility with current window security screens
  • Requirements
    1. Save energy cost with their home
    2. Easy to clean
    3. Sound proof

After shopping around for windows, Dick and Jane settled on triple pane energy efficient windows with removable sashes for easy cleaning and a laminated glass sandwich that should squelch out some noisy neighbors. They then picked a contractor that could handle the current security screens and paid the upfront capital for work to begin. All was well until they met resistance.

mm7Remember Dick and Jane live in a nice house, in a nice neighborhood, with a not-so-nice Home Owner Association. Upon the first week of window installation, they received a letter from their HOA advising them to cease all work until they submitted a request to the HOA detailing the change to their house. Although Dick and Jane own their nice home, they have come to realize there is a third stakeholder – the HOA and the HOA can be quite resistant. Lesson learned: always consider four major sources for risk – assumptions, constraints, dependencies, and resistance.

Summary

Business analysts need to manage risk associated with the development of requirements. Traditionally, they consider three major sources of risk: assumptions, dependencies, and constraints. However, business analysts are agents of change. Very few projects, if any, do not incur some level of resistance. Business analysts need to include resistance as a major source for risk along with the traditional three.

References

  1. Project Management Institute, A Guide to the Project Management Body of Knowledge 4th Edition, (Dec. 2008)

Don’t forget to leave your comments below.

Verifying Requirements Documentation

“Form follows function.”  This famous quote is sometimes attributed to the American sculptor Horatio Greenough, but in reality it was coined and made famous by Louis Sullivan, the American architect.  I thought of this architectural axiom when I read a BA Times article “Dazzle ‘em With Your Documentation Style!” (1).  In architecture terms, the article addressed the “form” of business requirements document (BRD).  Agreeing with the authors on enhancing the “form” of the BRD, I almost wrote a comment to that effect.  However, there was so much more I wanted to elaborate on in terms of the “function” of the BRD, I found myself motivated to write a “follow-up” article (reverse pun intended).  To be clear, “function” needs to be addressed prior to “form” in the BRD.  This article provides a checklist of best practices on verifying documented requirements – essentially the “function” of the BRD.

Verifying and Validating

Much has been said about verifying and validating the solution during testing at the end of a project.  An example of this is the V-model for testing (2).  Essentially in this model, the systems analyst verifies the solution to the specification followed by the business analyst/stakeholders validating the solution to the documented and approved requirements (assumes a waterfall approach).

  • Verification answers the question, “Was the solution built right?”
  • Validation answers the question, “Was the right solution built?”

However the same questions can be posed much earlier during the analysis phase of a project.

  • Verification answers the question, “Were the requirements stated right?”
  • Validation answers the question, “Were the right requirements stated?”

Documentation Best Practices for Stating Requirements

During the analysis phase, it is a best practice to validate the requirements with the stakeholders to ensure that the stakeholders agree (right requirements stated) with the stated requirements; typically this involves a signature to that effect by the business sponsor.  However, prior to validating the requirements, the business analyst needs to verify them (requirements stated right) with fellow business analysts.  Below is a checklist of questions for conducting this verification.  Each question is followed by the best practice rational.  Note that there is no order given for the questions; in practice the questions are considered simultaneously.

    • Benefit EstimateDoes each process improvement or software requirement provide a business value?  Rational:  Benefits need to be cited and claimed in the business case.  Project benefits typically are based on process changes rather than the implementation of software.  Software is usually the vehicle that allows process changes.  Also see Requirements Traceability.
    • Measurement (Leading and Lagging Metrics) Are process improvement and/or software requirements (conditions) measured?  Rational:  Measurements are vital to support benefits (delta between AS-IS and TO-BE processes).  Process owners adjust processes based on leading metrics (in-stream indicators) to ensure that lagging metrics (process end result) meet expectations.  Note that process improvements may be modeled via flowcharts, UML models, or Business Process Modeling and Notation (BPMN).  Also see Feature Decomposition – Conditions.
    • Transitional Process (Implementation Needs) Are special considerations during process or software change implementation documented?  Rational:  Particularly with a legacy system, there are one-time tasks such as file conversions that must occur upon implementation of a replacement system.  In addition, process changes may be implemented in phases. (i.e., parallel running of the legacy and replacement system).
    • Feature Decomposition Are features broken-down (analyzed) into their simplest components by separating capabilities, conditions, and associated business rules?  Rational:  Features are high-level business requirements identified during the project vision and scope effort.  Breaking down features and separating them into their capabilities and conditions provides detail solution requirements along with their associated business rules. 
      • Capabilities — Each feature needs to be broken-down into one or more system capabilities (i.e., read, store, receive, calculate, transmit) and are of interest to solution developers since they reflect the inner system workings or regulatory, business, and user needs.  Simplify the capabilities by eliminating all conjunctions (and/or).  These capabilities are called functional requirements and can be written as user stories, declarative statements, or use cases.  Each capability needs to be stated positively (avoid the negative) and in the active voice using verbs such as:
        • must/shall (mandatory)
        • should/may (optional)
        • will (provided by an existing or future system)
      • Conditions — Each feature can consist of one or more system conditions and are of interest to the infrastructure developers since they reflect the characteristics of the overall system support.  These conditions are called nonfunctional requirements and are documented as declarative statements.  Note nonfunctional requirements are equally vital to document as are functional requirements.  Nonfunctional examples are:
        • Performance – what data needs to be on-line and at what access response time
        • Capacity – how many users / transactions need to be accommodated
        • Scalability – what is the growth forecast of the system (i.e., data, users, transactions)
        • Availability – when does the system need to be accessible
        • Security – who needs access (create, read, update, delete) to the data
        • Usability – what characteristics are needed to ensure a quality user experience
        • Data retention – what data needs to be retained and for what period
        • Backup and recovery – what data needs to be copied and at what frequency
        • Disaster Recovery – if services are interrupted for a prolonged period, what contingency plans are needed for the system
        • Training – what training is needed for users
        • Documentation – what documentation is needed for maintaining the system
      • Business Rules – Do solution requirements refer to one or more business rules as needed?  Is each rule independently defined and numbered?  Rational:  Business rules are obligations that constrain solution requirements and are of interest to the solution testers since they reflect the input criteria for testing.  To allow business rules to change independent of solution requirements, they need to be uniquely identified for reference purposes.  Rule examples are:
        • Definition – The meaning of a unique term, word or phrase (i.e., glossary or data dictionary)
        • Relationship – The link between two or more terms (i.e., entity relationship diagram)
        • Calculation – Formula used to derive information
        • State – Data qualification that is caused by an event (i.e., state diagram)
        • Range – Valid values for a defined term
        • Authorization – Permissions needed to access or perform action on data
        • Condition – Circumstance under which a business rule may apply (i.e., decision table, decision model)
        • Trigger – Causes an activity or a message if a certain condition becomes true
    • Specifics – Are capabilities and conditions described in detail (i.e., who, what, where, when, and at what frequency/ volume)?  Rational:  In order to adequately test the solution, requirements need to provide the grade of quality needed.   Note requirements may be documented via user stories, declaratives or use cases.
    • Requirement Dependency – Are requirement dependencies documented?  Rational:  Requirement interdependencies may be needed in order to realize business benefits.  Dependencies can also be outside the scope of the project (i.e., existing systems or other projects).
    • Requirement Data – Are data needed by each requirement documented?  Are data defined and how they are created, read, updated, and deleted (CRUD)?  Rational:  Solution requirements encompass capabilities, conditions, and the data they use.  Glossaries, entity relationship diagrams and CRUD tables can be used for this purpose.
    • Requirement Order – Are requirements ordered by business value (benefit, risk, priority, etc.)? Rational:  The development team uses this order as a baseline when determining the technical order for development.  Note that the development team may propose a different order for technical or resource reasons. 
    • Requirement Traceability – Are requirements linked (forward and backward) to their original cited feature as defined in the vision and scope?  Rational:  Traceability is a risk migration strategy for maintaining scope.  If a requirement cannot be traced back to a feature, the scope has been expanded.  The objective of a project is to provide a solution within the project scope – no “gold plating.”  Whereas, the goal of customer service is to go beyond expectations – “wow” the customer.    
    • Requirement Accountability – Does each requirement have an owner to ensure stakeholder support and adequate information for change management?  Rational:  Signature approval of requirements is needed to show commitment to the solution requirements and the benefits they represent.

Summary

This checklist provides questions to verify that the “function” of the documented requirements follow best practices.  Once “function” has been assured, “form” can be addressed as a second step of the verification.  Note that requirements verification needs be followed by a stakeholder validation and a system analysis feasibility review.

      1. Verifying answers the question, “is the product or service being built correctly—per best practices.”
      2. Validation involves stakeholders confirming “that the correct product or service is being built—per business needs.”
      3. Feasibility is evaluating “that technology exists to implement the requirements—within project constraints.”

The above three steps needs to be accomplished prior to obtaining the project sponsor’s approval to proceed with development.  A similar verification with technical specifications and validation with requirements is done later on during solution testing.  As stated at the beginning of this article, this assumes that a BRD is developed using the waterfall approach.  Note the agile software development approach does not produce a BRD.  Verification and validation under the agile approach is conducted during testing at the end of each iteration (2). 

Post Script

At this point, I thought I would try to read some reader’s minds.  “Gee, the above checklist implies a lot of effort.”  Yes, it does.  Perhaps that is why it is called “work.”  Keep in mind that 40-60 percent of the errors in testing can be traced back to a poorly documented BRD (3).  We use best practices to reduce the risk of that happening.  Therefore, the amount of documentation effort needs to be based on risk.  To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question.

Don’t forget to leave your comments below.


References

      1. Spariosu, Nada and Rueffer, Patti (2011), “Dazzle ‘em With Your Documentation Style!” www.batimes.com
      2. Monteleone, Mark (2011), “A Proposal for an Agile Development Testing V-Model,” www.modernanalyst.com
      3. The Standish Group, The Chaos Chronicles, www.standishgroup.com

Mark Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University.  He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials.  He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business.  Mark is the President of Monteleone Consulting, LLC.

Can Parallel Thinking and JAD Save the US Congress?

This article proposes that the US Congress consider Parallel Thinking (Six Thinking Hats) and Joint Application Development (JAD) as methods for gaining agreements on various issues.  This year’s difficultly of gaining a compromise much less a consensus on the nation’s debt limit begs for a proven method for settling issues.  Due to partisan positions, simple negotiation methods have been ineffective.  Instead of deals being made via dialogues, congressional committees hold long drawn-out discussions that extend for months.  Parallel Thinking and JAD may be a solution for saving the US Congress from itself.  

Observation of the “AS-IS”

Little is getting done.  And it is hurting all of us.  Our elected representatives in Congress are diverse stakeholders.  Each have their own agenda with interests that in their view reflect what is best for our country.  It appears that everyone is talking and no one is listening.  Around the table of congressional committees are assertive individuals, each pushing their position and trying to dominate the discussion.  Essentially, their meetings are a series of discussions in which each person is attempting to win arguments while tearing-up the opposing views to pieces. 

What is needed is a process that provides a constructive and collaborative dialogue and an effective decision process. 

  • A discussion is an examination of ideas by argument or debate 
  • A dialogue is a conversation where there is an exchange of opinions

Proposal of the “TO-BE”

First and foremost, a neutral facilitator needs to be appointed by the committee chairperson for guiding the participants to hopefully a consensus or in the least case a compromise.  Note that the neutral facilitator provides process for meetings and does not participate in content.  The chairperson opens the meeting by stating the objective and then passes the floor to the facilitator.  After establishing meeting roles and rules, the facilitator introduces the parallel thinking technique called the “Six Thinking Hats” (1) to promote a dialogue on the meeting objective.   

Rules are vital to have a successful meeting.   The facilitator needs to gain an agreement that participants will treat each other with respect and most important focus on issues, not blame.

Below is a possible sequence of the hats:

  1. Blue Hat – the facilitator opens the meeting by establishing the objective, the six thinking hats process and the hat sequence that will be used.
  2. White Hat – each participant states only what is known (facts) and not known about the problem; like the character Detective Joe Friday, “Just the facts ma’am,” on the famous series “Dragnet” (2). Assumptions may be included, but they must be later confirmed as facts.
  3. Red Hat – each participant states only intuitive likes, dislikes, fears, hunches, and gut feelings on issues concerning the objective
  4. Black Hat – each participant states only the issues that are threats concerning the objective
  5. Yellow Hat – each participant states only the issues that are opportunities concerning the objective
  6. Green Hat – each participant states only how to address the threats and opportunities issues identified in the black and yellow hat dialogues
Parallel thinking forces each participant to consider all points of view and prevents one view from dominating the dialogue.

After conducting the parallel thinking dialogue, the facilitator then announces a follow-on technique for decision making.  Joint Application Development (JAD) is an effective technique for settling issues.  The facilitator explains this technique and how issues will be resolved (3).  During the technique explanation, the facilitator gains an agreement from the participants on additional meeting rules concerning a vital role – the decision maker. 

Essentially after the participants conduct a dialogue on the issues, the facilitator attempts to guide the participants through active listening and questioning – the end goal being a consensus or a compromise.  If an impasse develops, the issue(s) are resolved by a neutral person called a decision maker.  And per the meeting rules, the participants already agreed to accept the ruling(s) of the decision maker if needed.  This allows the meeting to progress and conclude with results that the committee can forward to the full Congress for an up or down vote.   

  • A consensus is when participants change their positions for the betterment of the group. 
  • A compromise is when participants make a deal, winning their view on some of the issues and losing on others.

So Who Is the Decision Maker?

As stated above, the decision maker is a neutral person that breaks through impasses. On a project, the role is typically performed by the project sponsor.  The guideline is that the person needs to be high enough in the organization to rise above the fray and decide on issues.  However, in this case there is no project sponsor and finding a neutral elected official is difficult.  Therefore, it is best to have a neutral arbitrator with no political affiliation.  One approach is for the chairperson to blindly select an arbitrator with assurances that the arbitrator’s identity be kept anonymous (Arbitrator Protection Program?).   

Summary

Unclear if Congress would consider any of the above methods even though they are proven facilitation techniques that are used in business analysis.  However, there is a sense of urgency that something is needed.  Just saying Congress is broken due to the participants is insufficient.  Process is needed. 

Writing this article has been somewhat therapeutic allowing me to put forth a constructive solution.  If you know of other proven facilitation techniques that would be useful in Congress, your comments are welcomed.  

Don’t forget to leave your comments below.


Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University.  He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials.  He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business.  Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

References

  1. de Bono, Edward (1999), Six Thinking Hats, Back Bay Books
  2. Webb, Jack (2005 release), Just The Facts Ma’am: The Warner Bros. Recordings
  3. Wood, Jane and Silver, Denise (1995), Joint Application Development, Wiley

(As seen in the International Association Facilitators 2011 October Global Flip Chart newsletter.)

So How’s That Working for You?

Often while teaching business analysis, students ask me, “Why should our business adapt any of these business analysis techniques?  We don’t use these techniques because they take too much time.”  My initial response is always, “So how is that working for you?”  This open question requires not only an elaboration, but some thought and not just a quick response.  It is also an effective question that allows me to start a dialogue with the student rather than a discussion defending the use of business analysis techniques. 

The word dialogue in Greek means to “talk through” as opposed to the word discussion which is derived from the Latin root meaning “dash to pieces” (1)

As the students ponder, I follow-up with some more focused questions to “pull” information from the student rather than immediately “push” my opinion onto the student.  “How are your projects performing today?  Are your expectations being met?”  These questions, of course, assume that they are tracking projects via measurements.  And by measurements I am not just talking about being on schedule, within budget, and delivering the stated scope.  I’m including the delivery of the benefits and/or compliance issues as stated in the project business case (discretionary and nondiscretionary projects). 

Often, project benefits are not realized until after project closure; therefore, they need to be tracked at the enterprise level. 

Continuing with the follow-up questions, “Does your business actually audit the business results?  Or does your firm declare victory upon the completion of a project and then move its attention to the next endeavor without any reconciliation of the business needs actually being met?”  Unfortunately, many firms only measure the project level “triple constraint” (time, cost, scope) while the tracking of the business results at the enterprise level goes unrecognized and unrecorded.

Success is not gained from the project execution, but in the business result it provides. 

Using active listening, I gain a better understanding of the students’ experiences.   Typically responses to my initial question are the following:

  • “Our project performance is good; our projects generally come in on time, within budget and deliver the committed scope” or
  • “Not so good. We have experienced some challenges in maintaining project scope along with unclear business results.”

With the former response, I advise the students if they feel project results cannot be improved then don’t change.  Of course, in reality there is always room for improvement; it’s just a matter of cost vs. benefits.  Along with this, I recommend that students consider benchmarking their results with other firms in their industry to ensure they are not missing an opportunity.  Competitors may have found ways of achieving better results, not only lowering cost, but gaining new revenue and deteriorating your firm’s market share.

Those who do not monitor their competitors soon find themselves working for them.

With the latter response, I advise the students that business analysis techniques lower the risk of maintaining project scope and ensuring business results.  These techniques are best practices and as best practices, they are proven to be effective and efficient in analyzing business requirements and process improvements.  Some of these are: 

  • Using the diagnostic approach
  • Modeling the current (AS-IS) and desired (TO-BE)
  • Determining root cause of problems
  • Measuring performance via metrics
  • Involving users
  • Building a business case
  • Defining and validating requirements iteratively
  • Tracing requirements back to the business need

I suggest to the students that they have before them the opportunity to help explain to their firm how business analysis techniques at both the project and enterprise level can improve their business results.   Their first step is to list the threats and opportunities for their business.  They can then gain support by developing stories that predict both positive and negative results for their firm.

Business analysis techniques lower the risk of maintaining project scope and ensure business results.

This means, of course, that their firm must change their current posture and adopt business analysis techniques at both the project and enterprise level.  Unfortunately, history shows that human beings typically are not motivated to change until they reach a cusp of a crisis.  Hollywood portrayed this behavior recently in a dialogue between an outer-space alien and an earth scientist on changing the nature of human beings to save the environment of their planet (2).   In this context, the key is for the firm to change prior to the demise of the business.

For change to happen, a sense of urgency needs to be established.

So in conclusion, “How is that working for you?”  If your answer is “not so good,” then you have an opportunity to take the Kotter’s first step in changing the organization – state a sense of urgency (3).  Start a dialogue on addressing the business threats and loss opportunities of not achieving business results (i.e., a business case).  After you have established the urgency (As-Is model), establish a team, define a vision (To-Be model), and conduct a gap analysis on how to make the transition using those business analysis techniques.  Yes, business analysis techniques do take time, but in reality they are time savers and saviors of the business.

Pay me now during the project or pay me much more later during the business.   

Don’t forget to leave your comments below.


Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University.  He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials.  He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business.  Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

References

(1) Cracking Creativity: The Secrets of Creative Genius by Michael Michalko, 2001
(2) The Day the Earth Stood Still, 20th Century Studio, 2009
(3) Leading Change by John P. Kotter, 1996