Living PIDs and Project Charters: the beating heart of successful software projects

One of the biggest failures in a software project is to write a PID or Project Charter and then move on. EventMAP’s Chris Thornhill explains why it’s so important to get them right at the start and why they need to stay as ‘living documents’.‍

The percentage of software projects that ‘fail’ – as in they don’t achieve the business outcome(s) set out within the agreed time and budget – is a frighteningly high 68%. The rate varies depending which study you read, but it paints a very poor picture of the health of project delivery in general. There are many suggested remedies: Agile, better requirements gathering, better stakeholder management, setting up a PMO – but in my experience it’s the start of a project that sets the tone and direction of any project and determines whether it will be successful. So, for a project to succeed, the PID or Project Charter is probably one of the most important documents to be created during the lifecycle of a project.

What is a PID/Project Charter?

The documents referred to as the PID (Project Initiation Document) or Project Charter are basically the same document depending on your Project Management methodology of choice, and vary slightly in content – but strive to do the same thing. (And, for my purposes here, the two are interchangeable).

They are created at the start of a project, defining what the project is trying to achieve (the outcomes) and they set out some key information which needs to be agreed between the client and supplier, who’ll be either an internal IT department or external third-party company. Whether the Project Manager is on the client or supplier side, or is part of a PMO organisation, they should assist in the facilitation of this knowledge transfer and the PID document should be the formal method to capture the information.

The Key Sections in a PID/Project Charter.

The PID/Project Charter cannot be written in isolation and needs the input and agreement from the key stakeholders. The document strives to articulate some very important information including context/background, objectives and what’s in and out of scope. There are other sections articulated in the document, but it’s these three sections that set out the direction and size of the project.

Context/Background

The context/background should be used to help set the scene for a project and to articulate the problem and the reason why the project is important to the client. This enables the supplier to be fully aware of the situation so that they can best solve the problem. It is important to note that both parties should work together to fully understand the problem and gain a shared understanding.

Objectives

The objectives section tries to articulate the desired outcome of the project. Rather than thinking about the solution you think you need, you should imagine yourself in the future, after successfully delivering the project, and describe the results you are looking for. I recommend avoiding weasel words such as ‘efficient’ and ‘sustainable’, and be more specific. I had a client who liked to use the phrase ‘like for like’, which is not a requirement, but in fact an aspiration which is wide open for interpretation. Some people express objectives as SMART Objectives, which is a useful technique to avoid them being ambiguous.

Sometimes, as a supplier (particularly if you are an external company) you are only part of a bigger project, so as a Project Manager in this situation, it is prudent to capture the client’s objectives, but then set out the supplier goals in support of the main objectives. This makes it clear to the client what is being delivered.

Importantly, the objectives are used in the planning phase of the project to ensure that any requirements gathered can be tied back to one or more of the objectives. Any requirement that does not support the objectives should be rejected or flagged up to determine whether the objectives have been clearly stated.

In and Out of Scope

This section tries to articulate how big the project is – for example “The delivery of Dell laptops to 1,000 users”. This helps to set out how much change is being delivered for the cost of the project. I use a technique which considers the seven areas of change (people, process, organisational, location, technology, data, applications) to ensure the limits and boundaries of change are clear.

Describing what is out of scope can be just as important (especially if the supplier is external) and sets out the limits of liability for the project. The supplier is setting out what work they are delivering and what is best handled by others – for example stating that communications to end users will be via the client’s communication team, or a point of contact resource at site will be provided by the client to handle goods being received, etc.

It is important that both parties understand what is changing and how big the change is, and, if the scope requires changing later down the line, the PID should be updated too or at least change request referenced. Note the later a change is identified in a project, the higher the cost of change – particularly toward the backend of a project.

Why is a PID/Project Charter Important?

The exercise of producing a PID is the first indication of how the relationship between the client and supplier will be. To get the best out of a supplier and therefore increase the probability of success, having an open and honest relationship is important.

The PID represents the first checkpoint for the project and its sign-off represents that all parties agree, and that the project represents value for money. It also provides the Project Manager with the authority to start, which means in practical terms spending money, noting at this point project costs will ramp up as resources start work on delivery.

Lastly, the signature on the document is a confirmation of commitment by all parties to support the project, and from a Management of Change perspective it indicates the current state is going to change, and this should be communicated to affected parties.

Can a PID/Project Charter Change?

Inevitably, situations do often change and this can result in a revision to a project. Changes should be captured on a change request form and the project impacted. As with any other aspect of the project this should include reviewing the PID to determine whether it is necessary to update it to ensure consistency across the project. A change should not be acted upon until agreement has been reached by the Project Manager for small/minor changes (within project tolerances) or by a suitable project board or committee for larger changes, especially if they require additional time or budget.

The subtle difference between the PID and other previous early documentation such as the Project Brief or RFP, which are one-time statements, is that the PID is kept up to date and hence is known as a “living” document – and should always represent the agreed understanding between client and supplier (particularly key stakeholders) throughout the lifecycle of the project. Without this control a project can quickly go off direction and the desired successful outcome can be significantly impacted, leading to dissatisfaction by the stakeholders.

EventMAP’s Project Management Approach to PIDs

Among the products and services that EventMAP provide are a number of professional services including project management. We can provide consultancy services to ensure your projects set off on a rock-solid footing, as well as providing support throughout your project delivery undertakings. We do, of course, use PIDs in our own engagements – not just because it is best practice, but because we always wish to form a good working relationship and we see the success of our clients’ endeavours as a measure of our own success.

‍Chris Thornhill is EventMAP’s Portfolio Manager and has successfully worked in project management for around 20 years for organisations such as the University of Cambridge and HP. He’s spent the last four years focusing on problems in space utilisation in room booking and timetabling.