Project Management Methodologies PRINCE2

[Former Member]

First question first: What is a project? (Many definitions in place and each passing day you will hear people with few new definitions), for me project is a requirement, of course a finite one which can be measured (in cost, time, quality and effort).

Prince2 defines projects as "A management environment that is created for the purpose of delivering one or more business products according to a specified Business Case” hmm... a bit complex in words but the methodology itself is not that complex.

Now back to definition of Projects: it generally involves number of stakeholders, leads to changes, has customers and providers, has definite expectations and most importantly bounded by "triple constraints" (Cost, Scope, Time and Quality). Also, note the so called “triple constraint” and emphasize that a project is really all about balancing the demands of cost, scope, time and quality.  So even though there are now 4 items in the triple constraint it is still called “triple”.

In Prince2 environment every piece of non-break/ fix work we do which results in a change to the Business Solution is delivered through a project. We use a Classification Tool and judgment as to when to set up a new project versus treating it as CI (continuous improvement) work that is to be added to an existing project. The factors that Classification Tool considers are:

1. Size the budget, resources and schedule
2. Manageability of business impact, technology, complexity, dependencies and deadlines
3. Others are risk, effort, cost, uniqueness, users impacted, sites involved, scope, manageability and complexity

I will try to explain this a bit more here: supposing you have 3 categories of projects:

• Category A: Work with 1 week to 2 week of effort and less than $30K budget
• Category B: Work with 2 to 5 week of effort and less than $100K budget
• Category C: Work with more than 6 week of effort and more than $100K budget.

Sometimes you would find category A included as CI in already running big/medium projects (of course after doing the initial impact analysis of including it in the project plan). The major factor driving the CI inclusion into a project is availability of resources, business requirement/dependencies, budget and time.

It is very important for you as a project manager to ask questions always to yourself or from business "is anything missing?" "Does anything surprise you here?" Integration is one of the primary roles of a project manager as he/she is the only people focused on the "big picture/final outcome".

Why do you think a project fails?  There are several reasons to this:

• Lack of identification and management of stakeholders
• Scope of the project is poorly defined
• business requirement of the project is vague or very complex
• the quality of the current data is poor or complex to convert
• Project dependencies not analyzed
• Poor task and resource coordination and integration
• Outcome poorly defined
• Poor estimation of resources, effort and cost
• Insufficient measures
• Lack of progress reporting and control
• Lack of a baseline against which to report
• Inadequate understanding of customer’s expectations (quality)
• Third party Vendor's inability to provide solution on timely basis.
• Last but the most important one: Project Manager's ability and experience.

So we have this scenario where we have all of these reasons why projects fail and organizations were/ are looking for ways to reduce the risk of this occurring. Thus they turn to methodologies and professionals who are good at running projects in controlled environment. You need both of these to be truly effective. Still requires the commitment of the organization to support and enable the PM and the method.

 What is a risk? Very important question just after the reason for the failure of a project

A risk statement would look like: There is a Risk that IF “x happens/ doesn’t happen” THEN “a consequence” will occur/ not occur.

Describe the major risks to the Project and all Risks should be added to the Risk Log. Risks may be identified during the sub-process and therefore it is important to setup a Risk log in the very beginning.

Always ask the question “What if you are not certain of all the benefits?”  The answer is that you should state this and also explain how you achieve certainty.

Now after we have defined the reason for failure and risk in a project let us get back to project and discuss more about it from planning perspective.

Project Brief: In PRINCE2 the Project Brief is the key Product created when “Starting up a Project”. The Project Brief is all about writing down what you know about the Project and the requirement it would be addressing. An ideal way to prepare the Project Brief is in a project preparation phase through running the various Workshops with the team involved and the Business.

It neither take days to write a Project Brief, nor it take ages to read it and understand/analyze it. Never forget that the purpose of the Project Brief is to provide the Project Board members with enough information that they can decide to initiate the Project "don’t go overboard with the information as you can always say it during the presentation"-- Point to be noted prepare yourself with all the cross questioning during the project board meeting for the approval of project initiation. Major factors driving successful project board approval are cost, time, quality and scope.

In the Project Brief we try to define and agree on the what, why, how, who and when of the Project. Again ask the question “Why do we produce a Project Brief?”.  Discuss points raised by participants in the workshops. A very valid question that might come in your mind is “Who gets involved in/ contributes to the Project Brief?”  Also, consider asking “Who prepares the Project Brief?”

The answer is of course in practice it will generally be Project Manager who prepare the Project Brief (it's not very difficult, important to ask questions during the workshops and most importantly asking questions from the right people).

There are following questions that will cover the Project Brief:

• Defines the formal terms of reference for the Project
• Are we all on the same page?  Where do we disagree? 
• What’s the agreed alignment?
• Customer’s quality expectations
• Agree the Acceptance criteria
• How do we know when the Project is finished?
• Initial Risk identification to start the contingency process
• Ensure that there is an outline Business Case, so we can define the Project Approach
• This would be used to facilitate authorizing the Project from the project board.

A sample project brief would cover the below (it might have few more addition to it):

1. Background
2. Objectives
3. Benefits Overview
4. Risks
5. Scope Inclusions
6. Scope Exclusions
7. Assumptions and Constraints
8. Stakeholder Acceptance Criteria
9. Project Organization
10. Dependency on other Projects
11. Product Outlines
12. Project Approach

Now let us try to address few of topics mentioned above in the discussion below:

Objectives:

List the individual objectives that collectively comprise the target for the project. The objectives should be measurable and relate to the dimensions of cost, time, scope, quality and customer satisfaction.

Try to keep the objectives succinct and simple. Aiming for one or two sentences which educates the reader as to what the Project is trying to do and what needs to be done. No need to get into benefits or outcomes here as these are discussed in the next section

Benefits Overview: 

 Expected outcomes of the project in terms of the benefits that it will provide to the company, it forms the heart of the business case defined in the project objectives. It's important to focus on outcomes not on outputs.

Ask the question "what if you are not certain of all the benefits?" The answer is that you should state this and also explain how you can achieve certainty.

Defining Risks:

I have already covered this above briefly, but would like to cover it here a bit more. 

If you really want to confuse yourself do Google "how to manage risk in a project" and you would come across hundreds of hits, each explaining the same method in different languages. So if you do not want to spend much time going through each of these, best to again organize a risk workshops in your project team and could also invite business, and try to address them with a initial questionnaire that you have prepared or you think are relevant to your project as a risk. During the workshop you will have a lot of addition to your questionnaire and you would come out of the meeting with a list of risk that might act as hindrance in your project.

But as I have said earlier keep asking questions to yourself "Am I missing something?" and this will always help you in covering the risk (not always though :)).

Scope of a Project: 

The range of activities and products that the project will consist of and will deliver as the outcomes. Scope has two important categories as explained below:

Project Inclusions/ In-Scope

1. Identify the major Products that will be created, modified, obtained or removed by the project
2. Define the boundaries of the project, eg
3. Geographic and organizational Coverage
4. Process/ Functional Coverage
5. Systems Coverage
6. Customer/ Supplier Coverage
7. Timeline
8. Identify and resolve conflicts

Project Exclusions/ Out of Scope

1. Most important to communicate what’s not being done or covered
2. Identify those items that Stakeholders may assume are in scope due to the nature of the Project, but are explicitly excluded.

Assumptions and Constraints:

List the assumptions and constraints which have shaped the definition and planning of this project. It is very important information to be shared with the Stakeholders. Constraints could include the following:

• Limitations imposed by management
• Implementation or other fixed dates
• Limitations on the skill/training of users of the final products
• Recognition of financial year or compliance issues or conflicts
• Limit on resources or costs
• Limit based on technology

Stakeholder acceptance Criteria:

Who is/are stakeholders? Anyone who is affected by or who might affect the planned benefits and outcomes of the Project either positively or negatively.

What are they expecting? A high quality delivery of a project with less time and cost. The Stakeholder’s quality expectations need to be defined and agreed at this early stage as they will impact the way in which Products are designed, developed and delivered.

Are we (Project team and Stakeholders) aligned? You should be specific with the requirement and set the expectations at the very beginning.

Agree and document the acceptance criteria: The best way to do this is create a PID (project initiation document) and get this signed off by the project board/stakeholders. The expectations and acceptance criteria will also be used in the initiation stage to create the Project Quality Plan.

Timeline is an important parameter to be defined as it ensures Stakeholders and the Project are aligned when the different products during the different milestones will get delivered.

Project Organization:

It is very important information which needs to be shared with the project board as it gives them insight on the resources who will be working on the project. Create and include a Project Organization Chart showing the composition of the project board, the key project positions and teams in the GDM (global delivery model fulfilling the onshore and offshore requirement).

Dependency on the other projects:

Your might be working in a delivery environment where there are many projects running at the same time, thus it becomes very important to identify and list the related scope items in different projects. Describe their relationship to your Project and also the governing factors that will impact your project.

For example: your project X is dependent on Project A for supplying design standards and project A cannot commence until Project C is completed.

Product Outlines:

You can list and briefly describe the key Products to be produced by the Project in your Project Plan also mentioning the different phases it will go through. It's important to think about what the Stakeholders would consider as as significant Products of a Project.

The number of products you will deliver will vary in different phases for example you might deliver 5 products in Dev and Build phase but will deliver just 2 in Final Preparation phase.

Project Approach:

In pure PRINCE2 this is a separate document and most of the client’s project delivery team try to merge it into the back of the Project Brief. Decide how the work should be approached. Take into account all the earlier content in the Project Brief (objectives, assumptions, risks etc)

Describe how the work will be done. It's always better to design the workflow or the process flow for your project which can also cover the dependencies amongst the different teams. Try to cover the quality checks applicable at the end or at the entry of different project phases. Also include the project approach in the GDM model (offshore/onshore or teams working in different time zones).

In the next Blog I will try to include PRINCE2 and also try to put my thoughts on how to blend it with other project management methodologies to use it efficiently to manage a SAP project(s).

In the meantime if you would like to read more on PRINCE2 try these sites:

http://www.prince2.com/what-is-prince2.asp

http://www.prince2.com/prince2-faqs.asp

[Former Member]

to other project management methodologies.  I think they all get to be really close to the same thing.  With minor differences.

I think this misses a big part of the project planning - developing a proto type.  Workshops, risks, assumptions...   All of those are nice.  But half the time your stakeholders do not even know what the technology can do. 

Also an interesting statistic to add to your blog series would be how many projects are kicked off after your project end.  Those that build on the solution already offered.  Do those following projects stop what was proposed?   Are they true enhancements?   Are the end users happy with the solution?  Any sort of statistics would be great!

Nice job - look forward to reading more and understanding the differences in PRINCE2.

Michelle

[Former Member]

Aren't these the same and if not please elaborate on deadliness so I can understand.

[Former Member]

Could you be specific with your question and elaborate more what do you want to know/understand. I will try to address it.

Thanks,

Sumit

[Former Member]

Thanks Sumit for the blog, its really informative and helpful, waiting for some more.

[Former Member]

Nice blog entry! I think the main differences of Prince2 to other project management approaches are:

* It is a consistent methodology that can easily be tailored to different projects. It is not a body of knowledge which just states project management techniques.
* It is from the same people who developed ITIL (OGC), so they likely do well together.
* It is easy to explain to other people (non project managers) what you do (e.g. executives). It is much easier to be on the same page than if you would use just a large body of knowledge. Everybody can understand the state of the project.
* Some big companies have adopted Prince2 (e.g. Deutsche Post DHL).

[Former Member]

Does SAP use prince2 also for project management