PRINCE2 Knowledge Train materials review

Those of you interested in project management probably are aware of the scarcity of free information regarding PRINCE2. Probably it’s due to the copyright claims (e.g. PRINCE2 manual is not distributed freely) and courses/training industry is attracting participants by not revealing a lot of the course content and materials, anyway.

Recently I was asked to review the PRINCE2 items provided by Knowledge Train. As a practitioner I was curious to browse through the free materials on their website and evaluate the result of their effort in summarising PRINCE2 in a couple of e-books. Surprisingly, everything I managed to read there is very useful. Not only the principles, the themes and the processes are explained well, the visuals (diagrams) are simply beautiful too. For example just looking at the ‘Starting-up a project visual’ makes it perfectly clear what is needed, in order to trigger the project, appoint people, why do you need a business case and what a lessons log is.

I remember when I first read the PRINCE2 manual – it took roughly two months to understand everything into details. And if somebody is up to the challenge of becoming a practitioner most probably the manual is still a must but why not starting with something simpler and easier to read. The e-books provided at the link below would definitely give you some overview and maybe even help decide if PRINCE2 is your ‘thing’ and if it would be useful for your organization and projects.

https://www.knowledgetrain.co.uk/prince2-ebooks.php

PRINCE2 documents / management products

I. Project trigger (by the Corporate/Programme)

- Mandate
This is the initial document to trigger the project. The minimum that it should contain is:
Reasons why the project is needed and expected change
The tolerance in terms of what is the maximum resources to be spend
Roles and responsibilities – at least the Executive and the Project manager (preferably) should be appointed

II. Starting up Project (SU) / pre-project

- Outline business case
The basic outline of a Business case. At this point it will contain the reasons, the options and the basic costs/schedule
- Project team structure and roles description
Roles and responsibilities of the team members and the appointed persons (by the Exec)
- Project definition
The scope of the project
- Project product description
Describes what is expected as a final product of the project (characteristics)
- Project approach
How the project product will be created /achieved
- Project brief
Consists of all the other documents so far in SU (does not include stage plan or the logs)
- Stage plan
-lans the initiation stage – if the Project board authorizes the initiation
- Daily log
Servers like a journal for the Project manager – all notes, reminders, issues should be in it (handled informally)
- Lessons log
Any useful lessons for this and future project should be stored there

III. Initiating Project (IP) / Initiation stage

- Full business case
The full business case should contain the entire business justification: benefits, costs, timescale, major risks
- Benefits review plan
A plan containing when, who, how and where the benefits will be measured both before and after the end of the project
- Project plan
(part of the Business case) The plan should cover all the stages after the IP and should contain costs/timeframe/responsible team managers, etc
- Project controls
The controls required to ensure the project runs properly
- Risk register
Details of all the risks and the mitigation actions
- Issues register
Issues that are handled formally
- Quality register
Individual quality check or activities
- Risk management strategy
How the risks are managed in the project
- Quality management strategy
How the project will ensure the product is “fit for purpose”
- Configuration management strategy
How the project will manage the configuration and the change requests
- Communication management strategy
How the communication will flow in the project. Stakeholders analysis and the needed comms
- Project initiation documentation (PID)
It expands the project brief and contains the full Business case, the strategies, the controls and the Project plan

IV. Controlling delivery stages (CS)

Controlling a stage
- Work package
Used by the Team manager (and created by the Project manager). The work package contains the entire information the team manager needs to deliver the specialist products (plan, budget, milestones, scope, techniques, comms channels, etc...)
- Stage plan (updated)
The main plan updated with actual details
- Highlight report
A report from the Project manager to the Project board regarding the current stage progress
- Issue report
Issue handled formally
- Exception report
If the stage is about to breach the foreseen and agreed tolerance

Managing product delivery (MP)
- Work package
Used by the Team manager in MP
- Team plan
Optional – created by the Team manager to meet supplier standards
- Checkpoint report
Report sent by the Team manager to the Project manager with the current progress of the Work package
- Delivery notification
When the specialist products are created/produced
- Specialist products
The products/items that need to be created and tested before being delivered

Managing a stage boundary (SB)
- Stage plan
Full plan for the activities and the results in the stage
- Exception plan
To replace stage plan if the stage plan goes off the agreed tolerance
- Project initiation documentation (PID)
Modifying and updating the PID where necessary
- End stage report
Report to the Project board accompanying the next stage plan and the updated PID

V. Closing a project (CP) / Final delivery stage

- Follow on actions
The follow-up documentation when the project is signed off and the final delivered product/s change ownership
- End project report
Final project report to the Project board consists of assessment how the project was executed against the PID and the Business case
- Lessons report
The good practices and the fields of improvement (mistakes) passed to the Project board and then to the Corporate/Programme
- Closure notification
To the Project board to be used to close the project to the Corporate/Programme
- Benefits review plan
Should be updated how and when and by whom the benefits will be evaluated after the project is completed. Post project reviews should be carried on by the Corporate/Programme

Digital/Web project management process

Whenever you are about to start new digital project you might wonder what exactly the process should look like, or what team members you need to engage? In this article I will describe the universal process and the most common team members involved.

I. Digital/Web project management process

1. Idea/requirements and rough estimation

Before the start of the project, there is the idea. It might be a customer’s idea or the product owner’s idea. The idea is then transformed into requirements and estimation in time, money and other resources is provided based on the requirements.

2. Signed contract or signed project brief/initiation document

If the customer or the product owner (stakeholders) agrees with the estimation you are going to have a contract or project initiation document signed.

3. Inception meeting

Inception meeting (with all project team members) purpose is not only to introduce the team members to each other. The project manager should organize the inception meeting with prepared project plan to discuss and approve by the other team members. Everybody in the team should know “what” and “when” is about to happen (different stages) and also “who” is responsible for every specific task.

4. Detailed requirements and specifications

The project manager and the product owner/customer should sit together and go through the requirements and get into details to clarify any queries. Clarified and detailed requirements are important so the transformation to well written specifications could happen.

5. Mock-up and design

The mock-up is just the outline of the visual structure of any design or feature. If you are going to manage a huge web project – mock-ups are mandatory to save a lot of time and resources. Once there is an agreement over the mock-ups the designers could finish the actual design (colors, buttons, backgrounds, fonts, fancy items, etc...)

6. Front-end coding

Once the design is done it needs to be turned into html/css code. This is what the front-end coders do. Also they add different features driven by javascript or other codes.

7. Beta development / back-end coding

The beta development could start even before the design. The back-end system is the backbone of your digital/web project. Every piece of data you see on the frontend is coming from database/code and the back-end developers ensure that the back-end system works without any flaws. Any critical and major defects/bugs should be fixed during beta revisions/development.

8. Final revisions and polishing

This is the stage where you need to involve the product owner a lot to ensure they/he/she is satisfied with the results. Any smaller issues should be addressed before the digital/web project is about to go live.

9. Going live and demo meeting

When you manage large digital/web projects it is important to allocate enough time and resources for the “going live” stage. Sometimes you need to ensure the hardware is going to stably sustain the traffic and the load and work closely with the system administrators too. It is always good to have a demo meeting in the end of every project, where the project manager, the product owner and/or the team members present the project’s features.

10. Maintenance and Support

These should be ongoing. Any future developments are better to be managed as separate projects and not just under support and maintenance.

II. The digital/web project team members

Below are the possible team members you are going to involve into a digital/web project.

1. Sales person

... or the sales team. They are responsible to gather the initial requirements (from the customer), to ask for rough estimation (from the design/development team) and have the contract between the customer and the company signed off. If the project is internal – the project manager is responsible for these steps (initial requirements, rough estimation, project initiation document signed).

2. Customer / Stakeholders / Management team / Product owner

This is the person (or the party) responsible to authorize the project, provide the requirements, and sign off and accept the delivered project. Also this is the person (the party) to address when the idea/requirement needs clarification.

3. Project manager

The project manager liaises with the rest of the team members and is responsible for the ultimate project delivery. Also the project manager is responsible for the entire project’s documentation – project plan, check list, gantt chart, specifications, project history, etc...

4. Design team

The team (or the person) responsible for the mock-up and the design of the project.

5. Front-end development team

The team responsible for html/css/javascripts, etc...

6. Development team

The team responsible for the back-end development, the software architecture and the backbone of the software project.

7. System administrators

The system administrators provide the hardware and the software support, to run the entire project. They also ensure that the system will have enough capacity to sustain the load.

8. Q/A team

Quality assurance is an important aspect through the entire project delivery process. The Q/A person matches the software with the specifications and ensures there are no defects and differences. If there is no dedicated Q/A team member, the project manager is responsible for stable Q/A.

PRINCE2 project management basics

PRINCE2 project management methodology is a Registered Trade Mark (Crown Copyrighted) of the Office of Government Commerce in the United Kingdom and other countries. Due to this fact I am only going to share some basics of PRINCE2. The following article is not to be considered as a substitute of the official PRINCE2 documents but just to serve as a basic source of information and also to provoke your further interest in PRINCE2. It is highly recommended to purchase additional materials and courses and also to visit the official PRINCE2 site for more information.

PRINCE2 introduction

The Projects in a Controlled Environment is effective and widely used Project Management methodology. It is a structured method and could be incorporated in the management of very huge and expensive projects in different fields. PRINCE2 is also pretty much traditional kind of approach – very structural and the idea is to ensure that the project is broken down into stages and each stage is delivered in terms of scope, cost and due time.

PRINCE2 principles

There are seven basic PRINCE2 principles:
- Business justification at all stages of the project
This is to ensure that the final product delivered by the project should remain valuable at all project stages. The product idea should constantly be checked regarding the environment and if any changes and updates need to be introduced – they should be. It is imperative that the product/change is still important and valuable for the company while the project runs – otherwise the project should be canceled.

- Adjust and learn from experience
It is important for the PRINCE2 team to learn from the experience of the past projects. And it is even more important to adjust the current project management style based on the experience with the current team and project scope.

- Clearly defined roles and responsibilities
It is pretty much self-explanatory. All the roles and responsibilities should be defined in a clear manner.

- Manage by stages
As a traditional project management methodology – PRINCE2 – encourages the project manager and the project board to break the project into stages and implement them one after another (using waterfall method).

- Define management boundaries
For example the project manager could be allowed to do some changes in the scope of the project if they are not going to cost more than certain amount or take more time to be developed than certain time frame.

- Focus on product
The focus should always stay on the product that is supposed to be delivered/achieved by the execution of the project.

- Tune up to the specific project needs
As PRINCE2 methodology could be used to manage small and huge projects – the method could be tuned to fit the current project needs.  Some projects could just incorporate some parts of PRINCE2, for example the project management team structure.

PRINCE2 themes

- The Business Case
The business case is usually the initial idea of product/change that needs to be introduced for the organization. It pretty much answers the question “why should we do this?”

- Organization
The project is always a temporary organization. The sponsoring organization needs to ensure that the proper team members are assigned and available to participate in the project. It should answer the question – “who is involved in the project?”

- Project scope and quality boundaries
The project scope should outline what needs to be delivered in details.

- Planning
The planning is very important part of PRINCE2 project management. All the plans should include the costs, the teams involved and the due dates for all the stages.

- Risk management
Just like in any SWAT analysis - it is important to identify the potential risks/threats for the project and to assess the impact if a particular risk situation happens. There should also be a backup plan “what to do if there is a significant threat to the project”.

- Change management
Although PRINCE2 is a traditional project management method – it allows introduction of “change” in all project stages. The project scope, specifications, team and developments - could all be a subject of change.

- Keep track of the project progress
Following a PRINCE2 project roadmap, the project manager should always be aware of “where is the project now”, “what should be done next” and “what was already done”.

PRINCE2 team

There are four major parties involved in PRINCE2 project management.
- Corporate and Programme management
These are usually the stakeholders or the board of directors of the company. They are responsible for authorizing and funding the project. They also need to delegate the proper management rights to the Project Board.

- Project Board (directing project management)
The company directors – like the CEO, OPS director, Business development director, other directors, senior users of the product, etc... They are responsible for the major project directing and need to authorize the project initiation, the different project stages and to quality check the completed stages in terms of the project scope.

- Project Manager (project management)
The project manager is responsible for the daily project management. The project manager is the liaison between all the involved parties and reports directly to the Project Board.

- Team Manager and The Team (delivering management)
There could be several team managers. Development team manager, design team manager, Q/A team manager, etc... The project manager should delegate the proper development and implementation of particular tasks to the team managers/leaders. The team managers are responsible for the development of the product in terms of costs, due dates and quality assurance.