What to look for to advance your consulting projects from contract to execution
Project Planning | By Michael Strange | Read time minutes
You've engaged a reputable consulting firm to perform a large systems project. You've prepared an RFP, carefully reviewed the responses, scrutinised the consultancy's oral presentation, and ultimately negotiated and signed a well-written Statement of Work (SOW).
Don't stop there.
A clearly defined SOW may place you on the right path, but it doesn't ensure success. In reality, the project manager engaged to run your project may not even be the person who wrote the SOW.
As an IT leader, you can and should do more to help advance your consulting projects from contract to execution. A careful review of the project plan is one way to facilitate this transition, and it's an underused and surprisingly effective method of finding early warning signs. So spend time reviewing the project plan and asking questions.
Here's what to look for:
1. Analysis, Preparation and Documentation Tasks Should Be Well Defined
Unless the requirements are 100 percent complete, most software projects require extensive analysis and planning in advance of design. For example, make sure there are tasks defined for process analysis, requirements definition and all related areas. Make sure there are tasks to discuss security, response times, user roles, data conversion, retention, reporting, preparation for testing (not just testing execution) and so on.
When evaluating the level of detail, many managers use the "40 hour" rule, which states that all tasks must take less than 40 hours. But it's more useful to include preparatory and documentation tasks. For example, look at how this project plan describes the steps for documenting requirements:
- Gather requirements, accounts payable (40 hours)
- Gather requirements, cash application (40 hours)
- Gather requirements, accounts receivable (40 hours)
- Finalise and get sign-off on requirements (40 hours)
The project team has two full-time people dedicated to documenting requirements, so they should be able to complete this segment in two weeks.
But consider rewriting the plan as follows:
- Eight meetings, accounts payable, two hours each (16 hours)
- Preparation, one hour per meeting (eight hours)
- Document results, four hours per meeting (32 hours)
- Repeat the pattern for the other functional areas
The new plan shows 56 hours of effort, rather than the 40 in the original. If this pattern holds throughout, you may be starting your project 40 percent over budget and not know it. With the rewritten plan, team members will see that the two weeks that had been allocated is not enough, especially given the difficulty of scheduling meetings. And if they can't tell you this kind of detail, they haven't thought the project through.
2. The Allocation Must Make Sense
Check the high-level allocation of effort. If the project is "waterfall" style, calculate the percentage of hours spent on each phase (analysis, design, construction, testing and implementation). If the project is "prototype" style, calculate the percentage of hours spent getting to the first and subsequent milestones. Take project management tasks out. The percentages should correspond to the maturity of your project. If the requirements are already defined, then don't accept the plan if 30 percent of the hours are allocated to analysis. If the project is in early stages of definition (and may evolve as work progresses), then don't accept a plan with 5 percent analysis.
3. Milestones Should Come Every 30 Days or Less
One of the easiest and most effective ways of managing multi-month systems projects is to use well-defined milestones. Demand a formal presentation of the design at one milestone. Schedule a review of the first iteration of prototyping at another. For straightforward custom-development projects, the milestones should be self-evident, and with formal review, they can be early indicators of success or failure. For newer, more complex projects (such as business intelligence or master data management), make sure your consultants have the expertise to define practical milestones.
4. Contingency Must Be Quantified, Not Buried
Contingency should provide a "relief valve" for unknown problems or unplanned work, and it should be included in virtually every project plan. If the project manager tells you that no contingency is required, his inexperience with the unknowns of large projects is showing. In my experience, once a custom development project is designed and a plan is carefully prepared, a 10 percent to 15 percent contingency is still warranted. More or less may be required, depending on the maturity of the project and the organisation.
5. Project Management Steps Should Be Defined, Not Assumed
Project management is a series of tasks, and those tasks should be included in the plan. Tasks such as documentation review and preparation of presentations and status reports are easily quantified. Don't accept a plan that includes technical tasks only and then adds just one person to serve as the project manager.
If you follow these rules, the project should progress cleanly. And since the plan will clearly describe tasks to be performed, you'll be better able to spot problems before they get out of control.
Then Follow Through
Signing a consulting contract isn't enough. Follow these steps to help the consultants spend more time on expertise-driven analysis and less time on logistics.
- Hold a kick-off meeting. Explain the goals, objectives and roles to everyone involved
- Be honest with your team. Clearly explain why outside help is needed
- Facilitate scheduling. Don't let the consultants flounder trying to schedule meetings
- Hold intermediate discussions. Help them focus on what's practical for your environment
- Help with formats. If your organisation has standards for presenting business cases, recommendations and ROI calculations, give these to the consultants in advance
Michael Strange is a client partner with Odesus Inc. in Los Angeles. Contact him at email@example.com
Recommended read: Project Planning a Step by Step Guide, by Duncan Haughey.