Evaluating the Quality and Effectiveness of a Completed Project Plan

Managing a project is only the second challenge that a project manager faces. “Management guru Peter F. Drucker said it all when he stated that one must measure before one can manage.” (Parth & Gumz, 2003) Preparing a project plan and measuring its effectiveness requires both time and skills. A project plan acts as a road-map guiding the project manager and his team and facilitating the processes. It further allows all team members to have a common document in which definitions, requirements, standards, procedures, timelines, reporting channels, estimations, and budgets are included.

In the following paragraphs we are going to suggest nine criteria that we believe allow a project manager to evaluate the quality and effectiveness of his/her project plan. Usually this assessment is rather hard before the project even starts: “It is especially difficult to do this during requirements development, as it is generally viewed as a writing activity that does not lend itself to quantitative measurements.” (Berenbach & Borotto, 2006) However, the below points will definitely aid in measuring such in the best way possible considering the circumstances:

Make sure that the scope of the project is defined clearly and in details and agreed upon with all stakeholders and project owners. Scope is the core of the project plan; messing-up this part will lead to a completely useless and misleading plan.

Did you include and detail all the different sections of a project plan? These sections usually are: Goals and Objectives, Project Estimate, Project Schedule, Project Team Organization, Risk Mitigation and Management Plan, Quality Assurance, Change Management and Control,(LOE, 2008) and Termination Management.

Check for consistency all through the project plan: go over each section and review its details making sure that it does not contradict with any previously stated aspect of the project.

Share the project plan with the team and get their feedback. This is a very essential point, team-members could provide crucial input allowing further enhancement of the plan or simply making it more feasible/realistic.

Concerning project estimations, one way to measure the effectiveness and quality of such after finalizing the project plan is to use a third method of estimation (supposing you already used two others) to check further the validity, accuracy, and correctness of your estimations.

Check previous similar projects and compare timeline/budget estimations: this suggestion is useful both before starting the planning stage and just after the project plan is done. Evaluating whether your project plan can measure up to previously devised ones permits you to learn from previous mistakes and ameliorate accordingly.

Present your plan to other trusted sources like consultants, senior upper management, and other PM friends in the same field asking their opinion and suggestions. This is not mandatory yet advisable; it is always better to have several inputs widening by which the perspectives from which your project is assessed.

Role based analysis: role playing is one of the methods used in different fields to assist in the evaluation process of several things in life. For instance, Yael Dubinsky and Orit Hazzan presented two research papers in which they use Role Schemes and Allocation in software development projects in order to “raise teammates' personal accountability while maintaining the essence of the software development method.” and another where they use the Roles Scheme to derive metrics.(Dubinsky & Hazzan, 2004) In our case, role based analysis can be used as another way to determine the soundness of the project plan from yet other “roles” perspectives.

My last suggestion would be to compare your planned processes versus the ones specified by approved maturity models. Maturity models such as the Software Engineering Institute’s (SEI) Maturity Model (CMM) for Software and the Organizational Project Management Maturity Model (OPM3) created by the PMI’s Standards Development Program can be used as reference models for assessing software development processes maturity and plans allowing software organizations to further evolve their processes. (Herbsleb,Zubrow,Goldenson,Hayes,Paulk; 1997). Remember that the quality of the product reflects the quality of plan used to create it. Sloppy plans cannot lead to quality products.

I hope the above summarized points assist you in assessing your project plans. Good Luck!

References:

1. Frank R. Parth and Joy Gumz (December 14, 2003) How Project Metrics Can Keep You From Flying Blind [online] available from: www.projectauditors.com

2. Brian Berenbach and Gail Borotto (May 20–28, 2006) Metrics for Model Driven Requirements Development [Research Paper] Available from: ACM Digital Library - ICSE’06 - ACM 1-59593-085-X/06/0005

3. LOE-Laureate Online Education (2008) Sample Project Plan [online] Available from: LOE as part of the IT Project Management Module.

4. Yael Dubinsky and Orit Hazzan (November 4, 2008) Using a Roles Scheme to Derive Software Project Metrics [Paper] available from: ACM Digital Library - ACM 1-59593-001-9/04/0011
5. James Herbsleb/David Zubrow/Dennis Goldenson/Will Hayes/ & Mark Paulk (June 1997) Software Quality and the Capability Maturity Model [Paper] available from: ACM Digital Library - ACM 0002-0782/97/0600

Define & Refine

Importance of Project Scope Management

Are you a project manager facing a failing streak? Are you having trouble in understanding the objectives and requirements of your project? You might want to consider focusing more on your Projects’ Scope Management aspect. Project Scope Management is the process of planning, defining, verifying, and controlling the requirements in any project. Making sure you have the complete requirements is the utmost consideration before starting any other process in a project. “The 1995 Chaos survey of IT executive managers listed the Top 10 causes for project termination to be:
1. Incomplete requirements (13.1 percent)…
2. Lack of user involvement (12.4 percent)…
3. Lack of resources (10.6 percent)…
4. Unrealistic expectations (9.9 percent)…
5. Lack of executive support (9.3 percent)…
6. Changing requirements (8.7 percent)…
7. Lack of planning (8.1 percent)…
8. Absence of need (7.5 percent)…
9. Lack of IT management (6.2 percent)…
10. Technology illiteracy (4.3 percent)” (Boehm, 2000)

The above statistics not only emphasize the importance of having complete requirements (13.1%), but, furthermore, highlight the necessity for scope management. Scope Management represents 31.7% of the causes for project termination (failure in this case) as portrayed above: incomplete requirements (13.1%) + unrealistic expectations (9.9 %) + changing requirements (8.7 %).

Stakeholders or project owners sometimes have unrealistic expectations. These expectations cannot surface unless scope definition is refined. Having unclear or misunderstood scope/objectives was listed as the number one risk in another survey performed by Addison and Vallabh: “All respondents indicated that the risk of unclear or misunderstood scope/objectives was very important… Aggregating the responses resulted in the following ranking of the listed risks: (in order of importance): — Unclear or misunderstood scope/objectives (Risk 1)” (Addison & Vallabh, 2002). Below is a chart showing the full results.




Fig. 1: IT Projects’ Risk Factors’ Importance Percentage as per the survey performed by Addison & Vallabh [2002]


While changing requirements is managed by the Control Management Plan, Scope Management allows the project manager to identify and report the effects of such a possible scope change avoiding by which any scope creep.
Marwan Abi Antoun in a recent research paper; while detailing his experience in an IT project which he referred to as “project BLUE”; mentioned what he considered as a “serious process mistake” referring to project scope creep which “introduced delays at various points” of the project. (Abi-Antoun, 2007)
Avoiding such scope creeps was cited in Addison and Vallabh’s paper quoting Keil et al. [1998]: “to avoid the problem of scope creep, project managers should inform users of the impact of scope changes in terms of project cost and schedule.” (Addison & Vallabh, 2002) In this sense, Scope Management has direct effect on the cost and schedule of a project which are considered two of three (third being quality) defining elements for project success.

Moreover, focusing on Project Scope Management permits the project manager to have a better understanding of what to expect through initial estimations he/she should make related to an original Work Breakdown Structure (WBS) devised as part of this management plan. “The risk of ‘unclear or misunderstood scope/objectives’ also occurs less frequently when the project is broken down into controllable portions.” (Addison & Vallabh, 2002) Breaking down the project along with their initial estimations, help further in identifying risks associated with any of the project aspects. These estimations are considered vital for scope verification. Stakeholders need to provide the project manager with enough input allowing him/her to verify the accuracy level of both his/her estimations and scope definition (along with many other aspects).

Project Scope Management’s real effect on project success or failure is mainly related to the question of understanding what problem or need is this project solving/fulfilling in addition to managing and controlling any possible changes that might be faced throughout the project processes. Appreciating the value of Project Scope Management will always pay-off favoring project success.

References:

Abi-Antoun, Marwan (October 21–25, 2007) Making Frameworks Work: a Project Retrospective [Research Paper] Available from: ACM Digital Library - ACM 978-1-59593-865-7/07/0010


Boehm, Barry (2001) Software Management: Project Termination Doesn’t Equal Project Failure [Article] Available from: IEEE Xplore and www.cs.unc.edu/~welch/class/comp145/media/docs/Boehm_Term_NE_Fail.pdf


Tom Addison and Seema Vallabh (2002) Controlling Software Project Risks – an Empirical Study of Methods used by Experienced Project Managers [Paper] Available from: ACM Digital Library.