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

Risk Management Software: Advantages & Disadvantages

“Australian companies are gambling the future of millions of dollars of software development projects by not implementing simple risk management schemes, an industry study has found.”(AFR, 1996) Risk management is an essential aspect of project management. Defining, controlling, managing, and eliminating risks helps project managers succeed in their relative projects.
Risk management involves many different techniques related mostly to risk analysis. Such techniques are sometimes complex and time-consuming as is the case with the Monte-Carlo simulation risk analysis technique. Due to such complexities, many software were developed to solve this problem.

Risk management software can be divided into two main categories: integration software and standalone ones.
By integration software we mean tools that were built in order to integrate with existing project management software. For example in case you want to use the Monte Carlo simulation technique “with Microsoft Project you need to have add-on tool.
There are a number of such tools available on market including @RISK for Project from Palisade Corporation (www.palisade.com), RiskyProject from Intaver Institute (www.intaver.com), Pertmaster software from Pertmaster Limited (www.pertmaster.com), Risk+ from S/C Solutions Inc. (www.cs-solutions.com).”(INTAVER, n.d.)


As for the standalone software, Riskworld.com (Tec-com Inc., 2008) lists more than fifty different risk-related ones that range from desktop applications to web-based applications. One example is “The Risk Manager” from RMSS: “The Risk Manager© is a user friendly application, based on the principles and workflow of the Australian and New Zealand Standard for Risk Management, known as AS/NZS 4360. The core process of Identification, Assessment, Control and Monitoring has been embedded in the application.” (RMSS, 2008)

Using risk management software, however, be it a tool or standalone software, has both advantages and disadvantages.

Other than the obvious advantage of saving time and eliminating the complexities of some of the risk analysis and management techniques, risk management software allow project managers through a user-friendly interface to access the latest tools to assess the project risks. For instance they provide answers to questions such as:
“
- What is the chance of your project being completed on schedule and within budget?
- What is the chance that the particular task will be on the critical path?
- What tasks affect the project duration at most?
- What is the project success rate?”(INTAVER, n.d.)
In some cases, such software allow him/her to, furthermore, get alerts regarding any risk that may have trespassed a preset threshold.
Having an online risk management application can also allow charts, tables, and different reports to be prepared in the easiest and most time-efficient manner.
Moreover, having the ability to integrate some application tools with the general project management software, enable the project manager to have a single management dashboard for the different processes involved.

As for the disadvantages of using such software, we could start by mentioning the additional cost involved which is on average around US$ 2000 excluding maintenance and support.
User-friendliness is not a common characteristic among such rigid scientific tools. Some risk management software require training while others have minimal or no proper documentation (especially the free tools). In similar cases, the risk management software will be time-consuming and even sometimes inaccurate in case misused.
Finally, relying on automated results in the form of charts and other types of reports to manage project risks could actually add unforeseen risks in case wrong or imprecise input was entered due to inexperience or simply by mistake, or in other cases where the software itself was defected or contained bugs. Some web risk management applications, for instance, might fail to provide instant critical information due to connection or server failure causing instant severe damage to the project’s timeline and/or budget.

To conclude, risk management software although built to help projects succeed with minimum or controlled risks, usage of such tools requires full consciousness of the consequences that might result from any related misuse.

References:

1. Australian Financial Review AFR (Thursday, 13 June 1996) “Cut risk or face costly software consequences, warns IT expert” [online] available from: http://www.zenkara.com/aust_fin_rev.pdf

2. INTAVER Institute Inc. (n.d.) Quantitative Risk Analysis with Microsoft Project [Online Article] available from: www.intaver.com/Articles/Article_MSProjectRiskAnalysis.pdf

3. Tec-com Inc. (July 21, 2008) Risk-Related Software [online] available from: http://www.riskworld.com/SOFTWARE/sw5sw001.htm

4. Risk Management & Safety Systems - RMSS (2008) The Risk Manager [online] Available from: http://www.rmss.com.au/Products/RiskManager.aspx

Project Schedule Conflicts

Often conflicts arise in projects between the different parties involved. Most of the conflicts, however, seem to be related in some way or another to the project schedule.

In the following paragraphs, we will try to identify the link between schedule issues and conflicts within projects.

Schedules are related to both time management and tasks distribution. These two aspects fall under the responsibility of the project manager. Project managers are responsible not only for managing conflicts, but also controlling and resolving any that might arise in this regards.

Conflicts related to project schedule are of many types and can arise on several different levels within the project team: stakeholders/management vs. project manager, project manager vs. team member(s), and finally team member(s) vs. another team member(s).

Stakeholders are usually concerned with projects meeting deadlines that are sometimes very stressful. “Every time you increase schedule pressure, you increase the likelihood of not meeting your deadlines.” (Richard, 2005) Any delay with the project schedule can cause a conflict between the shareholders and the project manager.

On the other hand, since project managers bear the responsibility of meeting deadlines, they might request more staff members or hiring a third party contractor for a specific job when they feel that the schedule might slip or in order to accommodate to some project change. Such requests might implicate budgetary increases and as a consequence create conflict again with the management.

Conflicts related to schedule between the stakeholders/management and project managers usually reflect on the project team’s schedule. Tighter deadlines, additional tasks, changes to be accommodated within the same deadline will surely add pressure on the project team and create further conflicts.

“Developers tend to think that managers don't respect them, or simply don't care about them. “I have to work yet another weekend because my Project Mangler, who clearly doesn't understand the first thing about software development, thinks that this feature can be done in 3 weeks even though I clearly stated that I would need 5”, is the type of comment often overheard from developers.” (Richard, 2005) This creates yet another type of conflict between the project manager and his team.

Furthermore, team member(s) unsatisfied with task distribution within the schedule provided might complain to the project manager. Conflict in this case might be due to the unjust distribution by the project manager, or the fact that some tasks are more important for future career advancement than others. For instance, discrimination against women is common in this sense. Some consider women less competent in completing certain tasks related to IT due to many gender related reasons. One paper written by four University of Arkansas graduates, highlights this fact with a full study entitled: “Barriers Facing
Women in the IT Work Force.” (Riemenschneider, Armstrong, Allen, and Reid, 2006)

Other types of conflicts can exist when project managers are discontented with the performance of their team. If the team effort is not enough, deadlines might slip. Project managers, in this case, need to find solutions in order to keep the project on-schedule and avoid further conflicts that might arise in case of failure in doing such.

“You might get lucky on a few features, but sooner or later, one of them will slip. And instead of working with you to catch up, the developer will start pointing the finger at you. Then you'll point the finger at him.” (Richard, 2005)

In case a failure happens in delivering any or all parts of a project, more serious problems arise. Blame-game is common in this sense between project owners, project managers, and project team. “Ultimately, people will start caring more about who gets blamed for what than saving the project.” (Richard, 2005)
This type of conflict might reflect into conflicts within the team itself. “Slippages in schedule are not the only source of conflict among developers, and concerns over the allocation of component tasks are especially prevalent among student teams, in which no line management accountability has been established.”(Hogan & Thomas, 2005) Each member starts blaming the incompetency or poor effort of other members in order to take the blame off his/her shoulders.

As a conclusion, project schedules and project conflicts’ are closely linked due to the stress and consequences often related with deadlines and tight schedules. Conflicts can arise between the different involved parties in a project. It is, however, the project managers’ responsibility in all cases to resolve such by using different approaches and skills including: leadership, communication, team motivation, incentives, clear job definitions, team balance, trust, commitment, accountability, discipline, and negotiation.

Reference:

1. Richard, Luc K. (November 7, 2005). Excessive Schedule Pressure [online] available from: http://www.projectmangler.com/content/regular/art20051107.htm

2. Cynthia K. Riemenschneider, Deborah J. Armstrong, Myria W. Allen, Margaret F. Reid (Fall 2006) The DATA BASE for Advances in Information Systems - Fall 2006 (Vol. 37, No. 4): “Barriers Facing Women in the IT Work Force” [Research Paper] Available from: ACM digital library.

3. James M. Hogan and Richard Thomas (2005) Centre for Information Technology Innovation - Queensland University of Technology. ACM International Conference Proceeding Series; Vol. 106 & Proceedings of the 7th Australasian conference on Computing education - Volume 42; ISBN ~ ISSN:1445-1336 , 1-920682-24-4; “Developing the Software Engineering Team” [Paper] Available from: ACM digital library.

LAST BUT NOT LEAST

Importance of Project Termination Planning

It is said that “you never get a second chance to make a first impression” (unknown, n.d.); however, you always have the chance to leave the floor with the best finale.

Project Termination Plan (PTP) is the roadmap for closing projects in the most successful manner. Project failure or success is irrelevant to the fact that a proper handover of the final product should be made. PTP is actually one of the criteria that differentiate successful project managers from struggling ones.
Why is it so important?

Early planning minimizes risks of failure. When a project approaches termination or closure its environment changes: resources start thinking or worrying about their next project; final testing adds to the stress; documentation becomes a present issue; installation, production, training, and change control guides need to be in place; necessity of financial closeout; management final reports; equipment handover; and finally a call for a lessons learned brainstorming session.

Without planning, all the above mentioned aspects will be hard to control and achieve. “As projects near completion, there is a natural tendency to minimize costs by transferring people as soon as possible and by closing out work orders.”(Visitask, n.d.) When your project team has already left, or is no longer focused, your termination process is at risk. “Project Termination is usually an emotional time for the project team” (Taylor, n.d.) For this purpose, project managers use the PTP as their guide to avoid such risks in the final stage of the project. “The Project Manager must plan for the termination phase well in advance of the scheduled project end – ideally in the development phase of the project’s life cycle” (Taylor, n.d.)

Managing the last minutes of the project life cycle highlights not only the leadership skills of the PM to control the siphoning of his resources, but, furthermore, proves the validity of his original plans. For instance initiating the documentation process only after the entire project is done will cause a schedule increase. Documentation should be preplanned to cover the different stages of the project allowing swifter project termination.

Documentation and training guides may be the most important deliverable of the project termination process from a client’s perspective; however, the lessons learned brainstorming session report is the vital element of project termination for project managers. This report helps both the development company and project manager learn from previous experiences thus allowing improvements to, and setting guidelines for, any similar future project management plans.

Having a project termination plan increases further the reliability factor of the management towards the project manager. “Although the primary emphasis in any project is to provide the end product to the customer on time and on schedule, the project manager must not forget that there are ancillary support items required in each project.” (Taylor, n.d.) Stakeholders care to know that the final product is not going to be an alien handed over in a rushed manner. Planned periodic audits, continuous support, and a well-documented product with an established change control mechanism constitute what is considered as a successfully delivered project. Moreover, the project manager’s management would surely recognize clients’ satisfaction towards project termination that will reflect positively on the development company’s reputation.

As for projects that are terminated because of some failure, PTP is equally important. “Project Termination can not even be disregarded for an unsuccessful project. Even in such a case, there are key learnings, team evaluations and other wrap-up activities to make the most of what has been done in the project.” (Visitask, n.d.)When projects fail people start blaming each other, getting rid of evidence, and leave the soonest possible in fear of relating their names with an unsuccessful project. “It can take some adjustment to realize that terminating projects can be natural and even healthy.” (Boehm, 2001) This fact makes the termination process even harder to achieve. PTP in this sense, especially if included in the signed-off project charter, offers the project manager the instructions and authority he/she needs in order to close this chapter in the most professional way.


Convincing a project manager to include PTP as part of their project plan should be made easier with the above advantages discussed. I believe the way to remember to do Project Termination Planning is to always associate it with the phrase “Last but not least”; although it tackles the Last or final part of the project, but it is surely not the Least aspect to consider when devising their project plans.

References:

Unknown (n.d.) First Impressions quotes [online] Available from: http://thinkexist.com/quotes/with/keyword/first_impressions/

Taylor, James (n.d.) A Survival Guide For Project Managers: Chapter 14: The Termination Phase - Second Edition – Page 275-287 [book] available from: http://books.google.com/books?id=QRoGPcBfTOkC&pg=PA276&dq=project+termination+planning+books&as_brr=3&sig=ACfU3U0qnI6W1jumP6aOQk_hvBxmQKoMDA#PPP1,M1

Visitask (n.d.) The Importance of Formal Project Termination Procedures [online]
Available from: http://www.visitask.com/Project-Termination.asp

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