Q&A - Predicting Project Outcomes Predicting Project Outcomes is about looking forward and focusing on the big risks. This will allow you to take positive action. Remember: You can predict a project outcome based on the quality of business requirements The cost of poor quality requirements is excessive The vast majority of people know the above 2 points, but do not take meaningful action on their strategic project to change project outcome.
Below is a selection of participant questions from IAG Consulting’s webinar on Predicting Project Outcomes with answers and explanations from VP Keith Ellis. To sign up for this, and other IAG webinars, visit: http://www.iag.biz/resources/webinar-events/
Q: How do you measure business requirements? Keith Ellis: To us, requirements are: 1. Clear 2. Accurate 3. Complete Each of these terms is defined for IAG so that we’re internally clear on what constitutes quality. You need to do this for yourselves. So often, the measure of business requirements is “did the stakeholders sign off.” This does not work well. Q: What are the key factors for predicting the outcome? KE: The requirements quality is a huge factor. An independent study reported that 70% of project failures are due to poor or missing requirements (InfoTech Research, 2006). This was confirmed by IAG’s own Business Analysis Benchmark, 2009 report which found that poor or incomplete requirements is the main factor leading to most project failures. Q: What are the practical methods to use for producing accurate requirements definition when you deal with business users and stakeholders that have poor IT knowledge and cannot actually define their needs? KE: The key issue is that you want them to describe the “what” not the “how”. That is - what does the business want to accomplish (in terms the way the process will work and the way information moves to
For more business analysis resources visit www.iag.biz
support the process) and not how will it do it (in terms of the interface, details of the application). Since this is not an IT-centric discussion, your stakeholders should not be mystified by the conversation. Let the IT professionals figure out how to marry up these discovered business needs with the technology. Q: Do you gather initial requirements, before creating Project Plan, or after creating Project Plan? KE: Requirements, project management, and governance are 3 interdependent but independent threads that need to be managed. Requirements can be done before, during, or after a project plan depending on how a company defines its SDLC, its funding and verification gates, allocates project management resources, etc. Be careful to separate the threads in your thinking. Q: Is project success based on project planning and management, heartiness of business case, or strength of technology? KE: To us, and in our research, project success is based on the perception of stakeholders. We also look at if projects met the intended primary and secondary objectives and time, cost, and functionality variables. There is a correlation amongst all of these factors to requirements quality. Q: What do you recommend to enhance the 'soft' skills of the analyst team? KE: Once the basic training or skills are in place I’d focus on co-piloting projects with an expert team. Soft skills are built through experience – and – through building confidence that the skills being taught will make them more successful than the approach they are currently using. This is a hard barrier to break through. Q: What skill set should be driving the discovery phase and at what time should the BA team get involved? KE: In the broadest sense this refers to a category called ‘elicitation’ skills. This is generally the ability to engage stakeholders and ask the right questions at the right time to proactively pull the content out of them that is needed. However, making people effective in this area is the more important consideration. A wider focus on people, process, technique, organization, technology, and deliverables is needed to make people effective. If you only focus on the skills piece, you may not get performance change. Q: Besides an audit, what are some options for meaningful action? KE: If you use these concepts to predict project outcome as suggested, you have many paths you can take: 1. Meeting with the steering committee to identify the unique risks of this particular project (scorecard it using the tool)
For more business analysis resources visit www.iag.biz
2. Meeting with the steering committee to determine what will constitute ‘complete’ requirements for this project 3. Establishing a peer review or manager review process for a project with the 3 content types required being central to the review. 4. Have the IT-delivery guys track requirements defects using the 3 variables mentioned. You then can relate this information to the overrun time on the project. 5. If the risk is high – look to engage an outside organization to do the initial organization of stakeholders and requirements discovery. Whether you use IAG or not for this activity, the path is still a strong direction for projects that are unusual in some way for your team. Q: How do you deal with a company that doesn’t know what they don't know - i.e. they don't know that their requirements are poor? KE: Usually when people show up at our door, there is some recognition that there is a problem. Most people don’t want ‘better requirements’. They want: Successful projects More efficient use of stakeholder time Process improvement / optimization Consistency of the process from analyst-to-analyst or project to project Legislative compliance (no publicly traded company should have poorly defined requirements processes. Eventually your auditors will flag this as a material defect because you are unable to report the true cost of projects.) Focus on one or two of the above 5 points to bring consensus to change. In your argument – focus on requirements as a process – not a document. If a key process in the company is broken, management must fix it. Q: Will the requirements define the scope or does scope control the requirements? KE: Both. Separate scope from a project management perspective and scope from an analyst perspective – these are two entirely different things. From an analyst perspective, scope is the context of the system in relation to organization and the high level scenario or business processes being impacted. This is ‘scope of analysis’. If you have excellent ‘scoping’ technique, the requirements are essentially an elaboration of this scope. Now, for the subtle twist, the requirements detail the scope of automation within the processes analyzed within the scope of analysis.
For more business analysis resources visit www.iag.biz