Posted on May 24, 2013
Ron Woodlock, Performance Architects
In my recent post “The Five Reasons Consulting Projects Fail” I focused on five project characteristics that determine the success or failure of a project. Those characteristics include:
- Executive support
- User involvement
- Realistic expectations
- Proper planning
- Clear statement of business requirements
Understanding that each of these must be managed effectively to ensure a positive project outcome is great to know. However, effective and efficient management is where the real work is. I’ve put together a list of recommendations to make the task a little easier.
- Don’t underestimate the effort required. Every project is different and presents unique challenges. Identifying challenges early and establishing the appropriate risk mitigation strategy will ensure that key stakeholders are on the same page throughout the project lifecycle. Anticipating challenges is an attribute of effective planning and can go a long way toward ensuring ongoing executive support.
- Tie back to the project’s objectives. Project best practices include the development and approval of a project charter document that is endorsed and approved by the project’s leadership. The charter should include sections detailing objectives, success criteria and scope. The project team should be reminded of these guidelines periodically. Project leaders should ensure that measures are put in place to track progress toward stated goals.
- Don’t re-invent the wheel. It is true that every project is unique; however, the project process and documentation can be standardized. Reusing documentation either as templates or as examples can save a lot of hours as well as improving the quality of the product.
- Use Business Analysts. “Business Analyst” (or “BA”) can be an ambiguous role. Wikipedia defines a Business Analyst as “someone who analyzes the existing or ideal organization and design of systems, including businesses, departments, and organizations. BAs also assess business models and their integration with technology.” A best practice for organizations that don’t have dedicated BAs is to identify individuals with the appropriate background and skills for temporary assignments on projects. These individuals get special training in this role and support from management. Having resources dedicated to performing the BA role will greatly reduce the risk of collecting poor business requirements.
- Involve all stakeholders. Before all stakeholders can be involved they need to be identified. There are many theories and tools that can be applied by the project team to identify stakeholders. Once identified, key stakeholders need to be actively engaged at the appropriate level within the project management structure. Reluctant stakeholders are the real challenge. Everyone is busy with their regular work so gaining commitment to participate is critical. Early escalation of lack of active participation by key stakeholders – as painful as it might be – could be the difference between the success and failure of a project.
- Systematically collect requirements. As discussed in item #2 above – having individuals play the BA role on the project goes a long way toward collecting solid business requirements. Adding a systematic approach to business requirements documentation is even better; stages we often use here at Performance Architects include: collection; revision; acceptance; development and testing. Low level details are best captured using a Requirements Traceability Matrix (RTM), generally in an MS Word format. For more information, see some of my other posts on building and using an RTM.
- Don’t lock down requirements prematurely. Most project plans provide for business requirements to be captured during the first quarter of the overall project timeline. Since this task is early in the project, there is a strong desire to stay on schedule and close out the process. Project leaders need to challenge the team to demonstrate that requirements have been accurately captured and vetted with the business stakeholders. Studies show that error in this phase of the project will have a multiplying effect later in the project.
- Validate requirements. Requirements validation sometimes requires some misdirection. Requirements gathering processes will usually focus on a particular point-of-view. An example might be the current process with a focus on pain points. The project team should review the results of the initial sessions with an eye toward finding flaws in the logic. Alternatively, during subsequent meetings, discuss alternative approaches to eliminating pain-points in the current process. The bottom line is: don’t be satisfied with one requirements session vetted with the business; you will need to iterate to develop comprehensive business requirements.
- Trace requirements through build and test. Building on earlier statements, capturing business requirements is just the first step. Leveraging the RTM during the build and test phases will help to ensure successful outcomes.
Author: Ron Woodlock, Performance Architects
© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.