Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Demand a Strong Project Plan

What to look for to advance your consulting projects from contract to execution

~ By Michael Strange

Gantt chart

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.

  1. Hold a kick-off meeting. Explain the goals, objectives and roles to everyone involved
  2. Be honest with your team. Clearly explain why outside help is needed
  3. Facilitate scheduling. Don't let the consultants flounder trying to schedule meetings
  4. Hold intermediate discussions. Help them focus on what's practical for your environment
  5. 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


Be the first to comment on this article.

Add a comment

(never displayed)

Out of 56, 14 or 27, which is the largest?
Notify me of new comments via email.
Remember my form inputs on this computer.

What Are Project Health Checks?

A doctor showing a clipboard with health check written in it

The health check is a reflective learning exercise, a snapshot of project or programme status used to identify what is going well and areas for improvement.

The Project Go/No-Go Checklist


Many project managers put an implementation or cutover plan together yet fail to carryout the rigorous analysis to determine whether they should proceed.

Requirements Hurried…Project Buried

Manager passing a document to a colleague

Innumerable studies have shown that Requirements Gathering is the single most important step in the Software Development Life Cycle.

When is a Project Manager not a Project Manager

Silhouettes of people from different professions

It seems that these days everyone claims to be a project manager. But are these 'true' project management roles? Let's find out what makes a project manager.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.

Latest Comments

Brent Tucker commented on…
Just for a Laugh: The Lighter Side of Project Management
- Wed 23 September 6:30pm

David commented on…
- Sat 19 September 3:18pm

Stuart Mori commented on…
Use Your Whole Brain: Leveraging Right-Brained Thinking in a Left-Brained World
- Wed 16 September 6:01pm

Latest tweets

General Project Management • Re: Project management tools about 21 hours ago

General Project Management • Re: How to choose the right requirements management tool for managing projects? about 1 day ago

General Project Management • Re: Best Certification For Me? about 1 day ago