PRINCE2 is a popular UK Project Management methodology, that continues to gain traction in other locations around the world. Now managed by Axelos, it is part of a comprehensive and integrated best practice suite along side other methodologies such as Management of Risk (M_o_R) and Managing  Successful Programmes (MSP). As such, is provides as alternative to the Project Management Institute's (PMI) A Guide to a Project Management Body of Knowledge (PMBOK), and it's Project Management Professional Qualification (PMP). Since the author holds both the PMP and PRINCE2 Practitioner Certification , it can sometimes be insightful to compare and contrast the two approaches to see what stands out in both.

The author always thought of the PRINCE2 "Themes" to be equivalent to the PBMOK "Knowledge Areas"; a specific sub-disciple of Project Management that was important throughout the lifecycle; for example they both have "Risk" and "Quality" in common. Then there is the PRINCE2 "Processes", equivalent to the PMBOK "Process Groups" - essentially the flow of phases throughout the Project Life cycle. They are both broadly like any good book or film, in that they have a beginning, a middle and an end - with of course a bit more complication along the way. But PRINCE2 has a third component: "Principles". I don't think PMBOK really has an equivalent, so I think PRINCE2 has an edge here; but what actually is a "Principle"? Without turning to the dictionary, I would instinctively think of then crudely like a "guiding beacon". They aren't detailed processes or procedures, they aren't step-by-step plans or rigorous methods. Instead they are are simple but critical focus points which must then permeate everything else we do in Project Management, something that we strive both toward. Why are they useful? Simple: because once you've got your PMP or PRINCE2 exam in the bag, that old textbook is transition into phase 2 of it's lifecyle: dust collector. You'll apply these methodologies competently of course, but you'll soon forget what precisely is actually in section 7.3.6.1 of the PRINCE2 handbook. But Principles are different; short and simple, if you forget all of the other detail and just focus on remembering them I don't think you'll then go far wrong

Ok Project Health Check you've got my attention, maybe these Principles could be useful in my Project. Tell me about them! Well this is just an initial insight, with our intention to focus on them in future articles - exploring our perspective and add some real life experiences along the way.

PRINCE2 Principles

1. Continued business justification
2. Learning from experience
3. Defining roles and responsibilities
4. Manage by stages
5. Manage by exception
6. Focus on products
7. Tailor to suit the Project Environment

What are your thoughts on these Principles, do you agree with them and can you think how they have played a role during your own Projects? Also, do you think anything is missing? Let us know your thoughts in the comments below!

Stay Healthy! Project Health Check - projecthealthcheck.org

Agile is a methodology which is getting more and more traction in the IT industry, to the point where the word is agile is thrown around out of context and with incorrect capitalisation. There are many variants, but a feature now common to many is the idea of a daily Scrum meeting to manage the work. In our experience, how this meeting is planned and executed will set the tone for the entire project, and how effectively they embrace the true Agile approach. Will it be truely Agile, or just "Agile", or even Watergile?

We've seen it done well, but also sometimes sickeningly badly - and made our own errors along the way. Here are our top tips for effective Scrum meetings:

1. Scheduling: The Scrum should be at a set time every day without fail, early enough in the morning to set the tone for the day but late enough to ensure everyone is consistently in the office in time! I suggest around 9:30 - 10:00 is ideal.
2. Timings: I suggest the Scrum should be 15 minutes in duration maximum top, short and sharp - any longer and you are just waffling. It should start on time precisely - be obtuse if needed to ensure this happens. If you're missing people, or they are having a chat then just start without them or over them - it might cause some angst for the first couple of meetings but team members will soon get the message. One problem is that many team members have poor time keeping - in fact it is our personal bugbear. Invite someone for a meeting at 09:30, and rather than be there ready, they will nonchalantly meander around to the meeting at 09:33 without a care in the world. To combat this we suggest that the meeting invite in calendars is scheduled for  a twenty minute period such as 09:30 - 09:50, but the meeting starts at earnest at 09:35 sharp. Use the first 5 minutes as buffer and for the obligatory morning salutations. Get a high quality visible wall clock, set it right and make sure everyone knows that is the master time clock - then there are no excuses! 
3. Sprint Burndown: The Sprint Burndown is essentially your status report on the Sprint, it tells you as Project Manager as well as senior managers who take an interest, how the Spring is progressing. Have the Sprint Burndown on a screen for all to see when they assemble during the buffer time; this will help foster the mindset that it is a team effort and the entire team is responsible for that progress. 
4. Stand Up: I'll be honest and say we didn't when I used to attend scrums, but I regret it. We always sat down and got nice and comfortable - then the meeting dragged on for half an hour. By physically standing up, it encourages brevity from participants.
5. Agenda - Each scrum team member provides an update on 3 things during the Scrum: what they did yesterday, what they will be doing today, what is blocking their progress. As PM you should be particularly interested to the blockers, catch the team members off-line after the Scrum to see if you can help remove those obstacles.
6. No Discussions - The team updates shouldn't morph into a discussions, if someone responds to someone or asks a question then the Scrum Master should start a visible egg timer in front of everyone with a 30 second time limit. As soon as that limit is reached you move on to the next update; discussions should take place immediately after the Scrum between the interested parties only, to stop wasting other people's time.
7. No External Input - Only the project team can contribute, that is those completing Story Points and contributing towards Spring Velocity. As PM this may mean that you don't contribute and are not allowed to talk! It depends how you translate the traditional PM role into Agile - in our experience the Scrum Master was typically more of a technical lead role, but PMs sometimes are Scrum Masters and we have done it before. But definitely no senior managers or external stakeholder interrogating the team or asking questions - shut them up and kick them out! If that means you as PM needs to take heat to protect the team: so be it.

Do you disagree with any of these, or would you suggest any others? Let us know your thoughts in the comments below!

Stay Healthy! - Project Health Check projecthealthcheck.org

We’ve said it before and we’ll say it again, Project Managers (PMs) live and die by the Plan. The entire purpose of the Start-up Phase of a Project is to produce a comprehensive Plan for the Project; consisting of an integrated Performance Measurement Baseline (Time, Cost, Scope) and an associated Project Management Plan to monitor and control it. Once the planning is complete, the Project shifts into the main Execution phase which will form the vast bulk of the timeline. The Project should then be reporting its status regularly to senior management via a Status Report, as part of its overarching Governance arrangement. So far so good; but when an organisation is orchestrating its status reporting process, what does it need to consider?

We’ve recently been involved in a review and update to the Project status reporting and governance structure for a major organisation with circa 150 Projects live projects at any one time. When you have that many Projects, the Project status reporting process needs to be effective and efficient to ensure the Organisation can “see the wood for the trees” – where does it need to focus its limited time and resources? Below we’ll outline up some basic high level considerations which we consider to be important; look on for more details on some of these points in future articles.

1. Management by Exception: This PRINCE2 Principle is extremely valuable as the starting point; the Project shouldn’t need to tell management about every single thing that it has done. The Project Plan was agreed and the Project now tracks to it; why waste time and effort restating what’s in the plan? The truth is senior management aren’t really bothered, or at least they shouldn’t be.
2. RAG: Red – Amber – Green. Very common terminology in the UK (“Amber” is the middle light on our traffic lights) you can call it Red – Yellow – Green if you prefer. This simple rating approach is pretty universal, and helps to implement step 1. A Green status means the Project is on-plan: management don’t waste your time asking any more questions. Amber status means the Project is a little bit off track, so keep an eye on us to make sure we’re ok. A Red status means we’re up a creek without a paddle – help! When you are dealing with a very large number of projects, RAG states help management see pain areas at a glance and then focus their attention accordingly.
3. Milestones: I’m not a fan of status reports with “Achievements this week” and “Planned for next week” – do they really want to know every task we’ve done and are planning to do? I have a very big schedule… But Project Milestones are different; high visibility key dates, they are typically tied to contractual requirements and financial payments. Reporting progress against these, or any risk to them, helps to give an appropriate view on progress without worrying about minor variations against individual tasks. Ideally, organisations should define as part of their standards a common set of milestones to be adopted by all Project to ensure consistent nomenclature and reporting.
4. Sub-Factors influencing Status: Reporting an overall RAG status is good, but in reality a Project’s Status is influenced by many factors. Effective reporting should ensure a Project report status against a standard set of sub-factors, which then collectively inform the overall Project status. These sub-factors may be different between organisations and industries, but should be common within the organisation, supported by an associated set of clear definitions. A good place to start when considering potential sub-factors is the Performance Measurement Baseline – the triple constraint of Scope/Cost/Time; how are we performing against these? What about the client relationship? If they don’t think the Projects going well then it doesn’t matter what you think. Risk is another factor; it’s nice if the Project is going to plan, but if there a lot of very severe risks stacked up that may impact at any time then the Project has the potential to go off course at any minute. There are many others of course: legal, commercial, safety, security, solution – the list goes on. Pick some, define them, stick to them.
5. Go-To-Green Plan: We’ve agreed the importance of the plan above, and if the Project Status is Amber or Red then clearly we are off-plan. What we need then is a plan to get back on plan – sometimes known as a Go-To-Green plan, or Corrective Action. If the Project is Amber or Red, management want to know that you have it in hand, and the GTG plan shows this. They will want to review it of course to ensure it is credible, and understand if they need to support it in any way – approving a Change Request to scope, making a priority call on key resources etc. In the worst case you may not be able to produce a GTG plan, in which case management will want to know when you will have one; a Plan for a Plan perhaps, or a Go To Amber plan.  
6. Reporting System Independence: The truth is that no one likes their Project to be Red, and understandably so – all you get is heat from senior management. The problem here is that sometimes PMs will keep on reporting Green when they should be reporting Amber or Red. This means that rather than getting the focus and support to fix their Project, the Project performance continues to slip until they are totally unrecoverable and yet another Project fails entirely. To counter this, Organisations need to foster an environment where being Red is not a negative; instead PMs get genuine support. Additionally, Organisations need to establish a reporting system what removes the ability to PMs to make potentially subjective and biased assessments of their Project’s status. Instead they should look to shift assessment of the key indices’ of Project performance out from their hands, and automate it based upon Project Performance Data. For example, cost performance data is collected by the PMO and the Cost Performance Index (CPI) is calculated and compared against defined Organisational standards to determine the Finance Status of the Projects – the PMs Judgement has nothing to do with it.

So there you go, some basic high level considerations for Status Reporting and Governance that we’ve used. What other considerations can you think of for designing Project Status Reporting processes? There are many other factors of course, and we may get on to them in the future!
​
Stay Healthy! Project Health Check - projecthealthcheck.org

Lean Six Sigma, a management buzzword that seems to persist and many don't understand. But what is it and how is it related to Project Management? Lean Six Sigma is an approach for Process Improvement Projects, combining many different conceptual tools depending on the situation. Essentially Lean Six Sigma is a fusion of two ideas: "Lean" and "Six Sigma":

Lean
Lean is a approach that seeks to eliminate Waste during a production process; it originated in Japan on the production lines of Toyota. It tries to make a process as efficient as possible, to reduce excessive costs and time - meaning the customer get the product they want faster and cheaper, the company improves their margin. It identifies seven categories of Waste which should be investigated and eliminated (though others have since been suggested):

1. Overproduction - It puts more pressure on the production process and reduces flexibility to change production
2. Waiting - Any time delay adds has a knock on effect on the final time to delivery
3. Transporting - Moving stuff costs time and money and provides no return
4. Over Processing - Gold plating additional features which aren't being requested don't provide a return
5. Inventory - Undesired costs to create and store products
6. Motion - Needless movement add time to processes
7. Defects - Obvious issues that need fixing

Lean will often start by interrogating the Process and conducting Value Stream Mapping and producing Value-Add Maps/Charts to show in detail what value every step in the process brings. It then used changes call Kaizen to fix these; small incremental changes that generate quick wins, made repeatedly to improve the overall process

Six Sigma
Six Sigma looks to improve the quality of the output of a process by reducing the variation of the output; it was introduced at Motorola in 1986 and resulted in $16 billion of savings. The term sigma comes from the statistical concept of standard deviation of the normal distribution; if points are normally scattered about a mean then one sigma is defined such that it would capture 68% of data points, 2 sigma would capture 95%, 3 sigma 99.7% etc. Six Sigma has a strong statistical focus, and defined in purely statistical terms a Six Sigma process is one in which 99.99966% of all opportunities to produce some feature of a part are statistically expected to be free of defects.

Six Sigma uses a lifecycle called DMAIC, that has five distinct phases each consisting of an array of tools that can be employed - depending on the nature of the project:

• Define - What are you actually trying to do? Define the Problem, the associated Goals, who in involved, the key measures and the rough timescales
• Measure - Quantitatively what is the current performance? Define a measurement plan and associated operational definitions, and check the quality of your measurement systems
• Analyse - Interrogate the data with statistical techniques to understand the process and it's performance. Understand weaknesses and root causes.
• Improve - Identify potential solutions, plan and implement them
• Control - Monitor implemented changes to confirm they have the desired effect

A Lean Six Sigma project can be a really effective way of delivering Process Improvement Projects - a distinct methodology from PRINCE2 or PMBOK. Alternatively, if you are managing mainstream project using either of these methodologies, you could then run a LSS Project using DMAIC on the across the Project processes themselves e.g. your demand management process, testing processes etc.

What are your experiences of Lean Six Sigma and DMAIC, good and bad? Let us know in the Comments!

Stay Healthy! Project Health Check - projecthealthcheck.org