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 mstrange1234@yahoo.com


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
1500
What is the fifth month of the year?
Notify me of new comments via email.
Remember my form inputs on this computer.

The Role of the Project Manager

A project management workflow diagram written on yellow sticky notes

A project manager is a person who has the overall responsibility for the successful planning and execution of a project.

The Role of a Business Analyst

A young businessman is sitting at a polished table attentively reading a document

This article examines the multifaceted role of the Business Analyst and gives a depiction of the duties and skills required to embark on such a career.

How to Do RACI Charting and Analysis

Project team in a huddle

RACI is a useful analytical tool that can be used to examine many problems in an organisation around clarifying who is doing what.

Progress Reporting

Green arrows reading progress

Progress reporting is an essential activity of project management. The project manager issues regular reports on progress against budget, schedule and scope.

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

Matthew commented on…
Why Over 90 Percent of All Projects Finish Late
- Wed 28 September 4:16am

Duncan commented on…
10 Rules of Highly Successful Project Management
- Mon 26 September 7:50am

John Corbett commented on…
10 Rules of Highly Successful Project Management
- Mon 19 September 1:36pm

Latest tweets

General Project Management • Categories of Communications? Need Advice. https://t.co/Bk2tEqauQb #pm #projectsmart about 13 hours ago

General Project Management • Best Certification For Me? https://t.co/KZdv5lIiKy #pm #projectsmart about 1 day ago

General Project Management • Re: Course Recommendation! https://t.co/R001FDPE3A #pm #projectsmart about 1 day ago