The Importance of Project Planning

The project management life cycle consists of five process groups (often referred to as phases): Initiation, Planning, Execution, Control, and Closure. It is important not to skip any of these stages if you want to keep your project from failing. For example, if you skip from initiation to execution without effectively planning the project, mistakes can be made, the project will be too disorganized, and it will fall apart. Likewise, if you, like many project managers skip the closure phase of the project management life cycle, you could risk making similar mistakes in future projects, not properly sealing the project, and more.

The purpose of the Project Planning Phase is to identify and document scope, business requirements, tasks, schedules, costs, risk, quality, and staffing needs. This phase include all the activities necessary for the project office to establish the project staffing, project infrastructure and stakeholder accountability, along with all the project management plans, including the appropriate levels of pre-planning documentation for the follow-on phases. This phase often executes in parallel with the Acquisition Life Cycle.
 The Planning Phase begins when the project has been formally approved and funded, and the Project Charter is approved. This Phase requires study and analysis culminating in the full Project Management Plan and that may lead to system development activities.

Acquisition activities are performed, if necessary, to obtain contractor support. The project work is broken down into specific tasks and sub-tasks, including the identification of project deliverables and assignment of allocated resources to each task. Control documents relating to that effort are produced.  The degree of project management rigor that is to be applied to the project is determined and milestones are established. Specific plans for management and governance of the project are established and documented to guide ongoing project execution and control. The Planning Phase ends with a formal review during which the adequacy of the Project Management Plan is determined.

Types of Plans
Creating a project plan is not a trivial exercise. The project manager needs to spend time gathering requirements from a variety of stakeholders and working closely with key technical staff to identify strategies and risks. For large or complex projects, creating even the initial plan may take several weeks. However, not all projects are “created equal” and some may not justify this amount of effort. Sometimes a project plan can be created on the back of an envelope (and, of course, captured in more detail during documentation – MS Excel is probably the most popular way many of you do this.)

• Exploratory Plans: these often begin with a conversation and some, “what ifs.” A creative developer has an idea for a potentially useful software tool or an alternate approach to solving a vexing problem. What makes these thought exercises a project that requires planning is the need for resources. It is one thing to have an idea. However to try it out and test its utility, someone has to approve the objective and the allocation of hardware and human resources. Even exploratory projects need a statement of the problem, a sequence of steps, a schedule and a method to evaluate outcomes.
• Agile Development Plans: I discussed Agile Development methodology in “Project Management and the Agility Factor” as a style of project development that focuses on short iterations of feature development. Kent McDonald, writing for ProjectConnections, suggests that a Project Plan for Agile Development would only cover a period of two to four weeks. “During those iterations, all of the necessary work to take features from an idea to a working product is completed …” Each iteration begins with a feature-based plan that includes detailed tasks, schedule and deliverables.
• Traditional Waterfall Plans: When waterfall development method is used on a project, the project management plan covers the life cycle of the project in discrete steps beginning with requirements analysis followed by design, implementation, test and maintenance. Because plans developed for waterfall method projects may cover months or even years of activity, these plans are more likely to require re-planning driven by external events.

Characteristics of a Good Project Management Plan
Here are a few tips to help you make a better project plan:

• Clearly defines the scope of the project
• Show dependencies between tasks as part of risk management
• Comprehend resource loading and realistic levels of effort
• Reflect awareness of project risks and allow time to understand and mitigate them
• Accompany the plan with a communication plan that explains goals, tasks, schedule and performance information with key stakeholders
• Include qualitative measurement of deliverables tied to project requirements (Focused on outcomes and not just widgets)
• Help developers, team leaders and users understand the project and their role in its success

Make sure the plan is sized appropriate to the scope and size of the project (“Not too big, not too small but just right”)

References:

http://www2.cdc.gov/cdcup/library/pmg/planning/

http://fearnoproject.com/2011/08/11/the-importance-of-project-planning-%E2%80%93-pmbok-chapter-3/

Success criteria of the project

Success criteria are the standards by which the project will be judged to have been successful in the eyes of the stakeholders. It is these that must be tracked to be able to answer the question of whether your project has delivered any benefits. 

There are 2 types of success criteria:

• Project: things related to the professional job of running the project.
• Deliverables: things delivered as a result of the project.

Here are his six factors for measuring the success of a project:

1. Schedule. Is there a hard deadline, or does the schedule relate to something else (budget, product launch date, etc.)? In the end, did you complete the project by the time it was due? Sometimes clients come to us with a hard deadline, other times they’re simply looking for the final product. Either way, my team always has a schedule we need to meet.

2. Scope. What do you need to get done within the timeframe? Tony refers to scope as the “stars that align to bring the client, the team, and you together.” It may be a list of features or just an idea, but the scope should essentially be the driving force of the project.

3. Budget. This is often the most important factor for many projects. In the end, did you stick to the budget? Did you come in way under budget? Your team should always know where they stand in terms of money spent. We regularly give clients a quote before they start and once we do so, we need to stick to it, or come in under. Otherwise we’re not a profitable business.

4. Team satisfaction. This is one that often goes overlooked in project management. “We often take our team for granted like a loyal friend, assuming that they’ll always be there when we need them,” Wong says. My philosophy is, I don’t ask my team to do anything I wouldn’t do. They need to have a life outside of work (although I know they all love coming into the Ciplex office everyday!), and work shouldn't feel only like an obligation. Keeping the team happy means if I do need them to work a late night here and there, they won't do it begrudgingly.

5. Customer satisfaction. Your clients might not be able to articulate exactly what they want, so often it’s your job to figure out what they’re looking for in order to make sure they’re happy with the end product. How do you track client satisfaction? Ask them to rate it on a scale of 1 to 10 every week or so, and analyze and review your findings. If my team builds a website the client loves, but the client wasn’t happy with the process, we failed. You can avoid this situation by seeking constant feedback.

6. Quality of work. The quality of one project often affects another, so it's important to always track quality and make adjustments to future projects accordingly. Remember, recommendations are like free advertising. If you deliver a strong product, your client will tell people about it, and that's where your next project should come from. (POZIN, 2012)

As with any other tool or technique, project success measures can be overdone. Use the following checklist to help ensure that your measures are good measures. They should be:

• Complete—anything unmeasured is likely to be compromised.
• Relevant—variances clearly indicate a need for corrective action.
• Valid—measuring what you intended to measure.
• Easy to understand—so that people will accept them.
• Economical to obtain—know the value of the information.
• Timely—in comparison to the result measured.

The bottom-line is this. Your project will be measured. Your stakeholders will decide whether it was well-managed. Someone will decide whether or not the project of your project was a success. Do yourself, your team, and your organization a service and get these measures documented and agreed to right from the start.

Bibliography

POZIN, I. (2012). ILYANEVERSLEEPS. Retrieved 2014, from http://www.inc.com/ilya-pozin/6-ways-to-measure-the-success-of-any-project.html