Does a Project Charter or Project Initiation Document Lead to a More Manageable Project Delivery?

Initiating a project usually involves writing one of two documents; a Project Charter or a Project Initiation Document (PID). Now a great many things happen during initiation. High level scope is determined, deliverables set and budgets estimated.
If these aren't investigated and documented effectively it can adversely impact the entire successful delivery. But which document is better for ensuring this?

Well to give a quick overview, a PID is a highly detailed paper which forces a PM to spend time upfront in seriously thinking about the deliverables, processes and governance required, before it even starts. A Project Charter is far less detailed and hence requires much less from a PM. It is essentially a quick way for work to get underway fast.

However, despite this, both documents have a similar feel and endeavour to fulfil the function of enabling effective initiation. But as you will have already seen, both definitely put the emphasis in different areas.
So which is better? Well if you have a small project then writing a long, convoluted PID doesn't make sense. On something this size it is highly likely the deliverable will be simple, the amount of resources utilised small and there will be just the one Sponsor.

Essential Documents to Manage Your Projects

Speak to an experienced project manager, and they can give you a wealth of good advice on the do's and don'ts to successfully manage any project. All this advice, in a nutshell, would be about how to manage the people doing the work (that includes you too), to deliver their results on time and to a budget, while keeping the risk of failure to a minimum.
It really doesn't sound that difficult to do, but for some reason, many people think that project management is a massive overhead to any project. I often hear phrases like "oh, don't waste your time planning the work, just do it!" or "why are you wasting your time writing the objectives, we all know what needs to be done!"
So the number one shortcut to successfully manage any project is:
"Understand the few essential brief documents you need to create and regularly review during the life of your project."

Document 1 - The Project Charter

For example, at the beginning of your project, you need to create a one-page document called the project charter. This document will make sure that you and your customer understand the general goals of the project. After all, if you don't know where you are going, how are you going to get there? Remember, you could also be your own customer!

How Managers Monitor and Control Worker Behavior

Managers have to monitor the activities of their team and the external forces. Without that monitoring you won't know whether your plan is working or if it needs to be adjusted. And managers must then control those elements that they can control to keep everyone moving toward the goal.

In the control task, you monitor the work being done. You compare the actual progress to the plan. You verify that the organization is working as you designed it.

If everything is going well, you do not need to do anything but monitor. However, that seldom happens. Someone gets sick, the database sort takes longer each iteration than projected, a key competitor drops their prices, a fire destroys the building next door and you have to evacuate for several days, or some other factor impacts your plan. The control step now dictates that you have to take action to minimize the impact and brings things back to the desired goal as quickly as possible.

That means going back to the planning stage and adjusting plans. It may require a change in the organization and you will have to re-direct everyone toward the new goals. Then you control the new plan and adjust if needed. This cycle continues until you complete the task.
Here are some additional aspects of Monitor and Control:
Keeping Score Isn't Winning
There is no point in monitoring if you don't take action based on the information. Don't just keep track. Make sure you are measuring the right things and then take appropriate action to fix whatever problems the measurements point out.

Chartering Projects

Formal chartering may be the step most frequently overlooked by organisations when beginning projects. Root cause analysis of project failures often identifies "poor vision" or "lack of a charter" as a key reason projects go awry or are cancelled.
Knowing this, why is developing a good project charter apparently so difficult? It is certainly not due to any complex technical reason, like not being able to find a word processor advanced enough to document the information. There are a few reasons so many projects have ineffective charters.

Business managers that sponsor projects are not experts in project management. The care and nurturing of projects are merely a fraction of their job duties.
Business managers simply need results. Many times they feel their responsibilities are complete if they simply identify the problem to someone (like a project manager) that is assigned to correct it. If it is the role of the project sponsor to create the charter, they may need some training or assistance in order to develop a charter that serves as a foundation for future project work.

Why Businesses Should Use MSP Programme Management

MSP (Managing Successful Programmes) is a best-practice guide from the OGC (Office of Government Commerce, an independent Office of the Treasury). It has been developed using the collective expertise and practical experience of some of the leading practitioners in the field. Managing Successful Programmes is unique in its status as a flexible generic best practice framework, and although it has been founded on best practice, it is not prescriptive.

MSP describes programme management as a "pragmatic, robust management approach that will help organisations to deliver and realise the required benefits, innovation, and new ways of working that will ensure success with major projects and programmes of business change."
Managing Successful Programmes provides a business or organisation with the framework and strategies of programme management - in other words, providing an approach for managing change and delivering business benefits from a set of related projects.

Understanding MSP Programme Management

For any organisation or individual that needs to manage and control related projects (portfolio of projects), Managing Successful Programmes (MSP) programme management is a management tool for bringing together people, activities and information to achieve the end goal.

History of MSP Programme Management

MSP programme management was developed by the Office of Government Commerce (OGC), an independent Office of the UK Treasury, and supported by a full range of commercial partners. It was first released in 1999, and in 2007 a third version was released to reflect the evolving knowledge of programme management. MSP programme management is the UK Government Best Practice standard for effective programme management, and is a globally recognised qualification.

What is Programme Management?

A programme is made up of a number of projects identified by an organisation that will deliver a defined objective, or set of objectives, for the organisation. A programme can only succeed if the projects within the programme are completed, therefore, without programme management, the projects would be uncoordinated and not integrated into a final goal.

What is Change Management?

The change management process is key to the successful outcome of a project. The process ensures that each change introduced is properly defined, considered and approved before implementation. Change management contains four stages:

• Proposing a change
• Summary of impact
• Decision
• Implementing a change

Proposing a Change

This process give the ability to anyone within the team (including the customer) to propose a change to a project. The proposal must include a description of the change and expected benefits or other reason for the change and is presented using a Change Request Form.

Persuasion and Perception

Every year, between forty and seventy percent of all corporations and public sector bodies attempt to make strategic change. Overwhelmingly, formal projects are the preferred structure used to organise such effort, regardless of whether the underlying goals are defined in terms of business process re-engineering (BPR), technology upgrades, mergers and acquisitions, due diligence or similar concepts.

Each organisation starts with a desire to make itself better. But "better" is a slippery concept. Certainly projects bring about change, but do they necessarily make things better? Better in the board room might mean lower costs through reduced head count, but would the rest of the team agree? Perspective matters.
In the absence of personal control of events, everybody hates change. A failure to remember this fundamental insight is the root cause of a great many failed projects. Sophisticated communication strategies and planning models may impress project owners, but these tools will not persuade a hostile group of users or stakeholders that a new project will improve their lot in life; certainly not when their instincts and reflexes are telling them to resist.

Forecasting Support Costs

Did you know that maintenance accounts for 50% to 80% of the overall product cost? Well, it does! And while most project managers are fairly good at sizing new product features, many are terrible at estimating the effort required to support a product once it becomes generally available. As a result, maintenance projects are inadequately staffed, companies can't respond to customer requests in a timely manner, and products never reach payback.
This article presents a methodology to help you guesstimate and therefore plan for the maintenance phase of generally available products. But first, let's define a few terms that are important to the comprehension of this article.
Maintenance
Maintenance is defined as the effort associated with fixing defects in a software system after general availability (GA). In other words, how many person-months will it take your organisation to fix bugs discovered by your customers in the field?