First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Monday, 23 May 2016

Better Sheepdog Book of Knowledge (BSBOK) Examination

To prove that you have studied the Better Sheepdog Book of Knowledge (BSBOK) requires an Examination which is in the form of a crossword puzzle as Project Managers need to be able to solve puzzles to deliver their Project!

Anyone emailing successful answers to bettersheepdog@gmail.com will go into the Hall of Fame. Please supply your name and your personal Project Management slogan / comment.




Better Sheepdog Crossword Puzzle



You can print the crossword puzzle via this PDF


Across
3.This is one of the 4 leadership styles suggested by Better Sheepdog? (8)
6.Kipling recommends six honest men help with Project definition according to Better Sheepdog. What is the longest name of one of the men? (5)
7.Better Sheepdog says that Newton's first law of motion can be applied to change management, fill in the missing word -People tend to continue travelling in the same direction.....unless acted on by an external xxxxx? (5)
8.Better Sheepdog says there are two dimensions to success in a Project. One dimension is for the Project Team, who owns the second dimension? (7)
14.Complete the Proverb, "Those who cannot remember the past are condemned to xxxxxxx xx"? (6,2)
16.According to Better Sheepdog, what is the special risk to consider on an IT Implementation regarding people spotting "problems" which already existed? (4,5)
18.In the six "thinking hats" approach to meetings, what coloured hat does a person wear when expressing traits such as optimism, positive, opportunities, benefits? (6)
19.A RAID log covers 4 key aspects to be managed and it is an acronym. What does the letter "A" represent (plural)? (11)
20.Fill in the missing word in this phrase? Good estimators aren't modest, if it is xxxx, they say so! (4)
21.To ensure that your project documents are fit for purpose, Better Sheepdog suggests that you need to produce a planning document named? (7,4)
23.According to Better Sheepdog, Resource Planning could be better described as “Establishing your what” (7,4)?
25.What is the name for the storage structure used for organising project documents? (7,4)
27.A standard risk assessment to be carried out for all resources is “How will the project cope if the person is suddenly unavailable for an extended period”. Better Sheepdog calls this assessment what? (4,5,1,3)
28.From your planning, anything which needs to be delivered but isn't part of your Project scope is called an External what? (10)
31.What skill does Better Sheepdog suggest that an effective Project Manager has to obtain information and support from various sources, sometimes on an informal basis? (10)
32.What does Better Sheepdog recommend be confirmed about the Board members in the first Project Board? (16)
34.Fill in the missing word in this Better Sheepdog phrase? xxxxxxxxxx kill IT Projects! (12)
36.What does Better Sheepdog suggest that each Planning Assumption represents to your project? (4)
37.Fill in the missing word in this phrase from the Ancient Greeks? Everything xxxxxxx and nothing stands still (7)
38.What is the Better Sheepdog name for the often used but least good approach for assuring the quality of documents produced by the Project - Review by what? (11)
39.Name the person (role) who owns the Project and especially the Benefits? (7)
40.What type of meeting does Better Sheepdog suggest that you hold before starting a critical Project Phase? (5)
41.When running a meeting what does Better Sheepdog suggest the meeting organiser does to set the scene and objectives? (4,2)


Down
1.Honest communication is an important behaviour to look for in a Project Manager. Complete the Proverb "The most valuable and least used phrase in a Project Manager's vocabulary is x xxxx xxxx (1,4,4)"?
2.What planning should go on with regard to the Benefits of the project? (11)
4.The Better Sheepdog way of remembering key Project Management prompts is Humour, Pictures and what? (8)
5.When you have a list of project stakeholders, how does Better Sheepdog describe how you put them into different buckets for ongoing management? (7)
9.Complete the Better Sheepdog Proverb? "Nothing is xxxxxxxxx for the person who doesn't have to do it!" (10)
10.Fill in the missing word in this phrase? Estimators do it in group, top down and xxxxxx up (6)
11.Planning is important but should be balanced with what according to the Better Sheepdog Proverb "Planning without xxxxxx is futile, xxxxxx without planning is fatal"? (6)
12.What does Better Sheepdog suggest that you should you do with Risks before the Risks do the same to your Project? (6)
13.Before embarking fully on Project execution what document should be used to confirm that organisation funds and resources are being used on the correct Project (8,4)?
15.The Better Sheepdog approach to producing a Budget during Initiation is a spreadsheet with a calendar broken down by what? (5)
17.You need to escalate to your Sponsor as the Project is forecast to be outside agreed targets. What is the wrong method to raise this escalation? (5)
22.What very useful PRINCE2 document (one per Product) to help ensure a good quality product does Better Sheepdog suggest need NOT be created in some circumstances where the principles are handled elsewhere? (7,11)
23.What does Better Sheepdog suggest that you may have to throw in regard to say a difficult stakeholder or team member (7,5)
24.When producing a schedule, who shouldn't be on the critical path as a resource undertaking a task? (7,7)
26.The accuracy and quality of plans often degrades over time from today. Better Sheepdog calls this what? (8,5)
29.What is the Better Sheepdog partner to Planning as Clyde was the partner to Bonnie? (10)
30.Complete the missing word in the Better Sheepdog proverb - What is not xxxxxxx has not been said! (7)
33.Fill in the missing word in this phrase? If Project Scope is allowed to change freely the rate of change will exceed the rate of xxxxxxx! (8)
35.What is suggested to manage stress in the Proverb "A xxxxx a day keeps the stress away!"?
38.What type of report does the Project Manager produce near the end of the Project? (6)
39.Fill in the missing word in this phrase? Q-How do Projects xxxx? A-one day at a time (4)

A Rival to the Project Management Book of Knowledge (PMBOK)?

The two year project to brain dump my thoughts on improving Project Success is near a close with some hopefully informative posts accompanied by cartoons and proverbs to occasionally amuse you. I therefore want to commend this Blog to you as a reference site to use in future as you manage your Projects especially if you are fairly new to the role. 

As a rival to the PMBOK I will call it the BSBOK which truly appeals to my sense of humour :-) [Better Sheepdog Book of Knowledge of course!]
Better Sheepdog Book of Knowledge

How to use Blog as a reference site

This is covered in more detail here but in brief you can click on the Tags button in the right hand margin and select a topic label or I find Search at the top of each page works well. So if you are doing some planning and want to look at guidance, either look for the topic label or enter the word "planning" in search.

BSBOK Examination

Like any good Project Management approach, there needs to be an Examination. I think any good Project Manager needs to be able to solve puzzles such as:
  • how am I going to get the plan back on track?
  • how am I going to address this difficult stakeholder?
Therefore the Examination will be in the form of a Crossword puzzle and can be found here.

Anyone who emails bettersheepdog@gmail.com with the correct answers will go on the site honour board, good luck!

and finally Thanks...

Lastly, I want to thank my colleague Manoj for encouraging me to commence this Blog back in 2014 and to all of my followers for reading & commenting on the posts during the last two years. 

Friday, 13 May 2016

Why Projects Fail and how to address?

The objective of the Be a Better Sheepdog Blog is to help you improve the success of your Projects. So I thought it was a good time to take you through some well publicised reasons for Project failure and point you back to previous posts where I have given some guidance on addressing to give you the best chance of not suffering such a fate and having to employ the strategies suggested in the cartoon :-)
Project Failure - Strategies for handling

No Business Benefits from the Project

The Business benefits of a Project are defined as a key success criteria for the Project Sponsor. 

This failure point can be addressed by:
  1. Ensuring the organisation undertakes the right projects which should deliver sufficient benefits and return on the investment made
  2. Ensure there is a good business case produced for the project during Initiation
  3. Keeping the business case under review during the project life-cycle - see more in this post on PRINCE2 principle Business Justification
  4. Producing a Benefits Realisation Plan during the project execution phase to ensure the detail on the benefits in understood, when they will be measured and who is accountable
  5. If changes to operational business processes, team structures and responsibilities are involved in achieving the benefits, plan this carefully considering the human resistance to change as described in Newton's first law of motion

Confusion during execution on what the Project should deliver

  1. The Project needs to have clear ownership via a Project Sponsor and augmented by other roles to form a Project Board Using the analogy of a ship, the target port (objective) for the captain and crew (project manager and team) should be set by the ship owners and the route (plan) should be confirmed when proposed by the Captain (project manager)
  2. By the end of Initiation the Project should be properly defined with the outcomes, acceptance and success criteria clearly understood and agreed by both Owner and Team
  3. As you progress through the project life-cycle, lower level detail will be defined with agreement on a set of detailed requirements. Don't forget that you need to have performed a good Stakeholder analysis to consult the right people when developing these requirements and always consider the risk of communication problems leading to mis-understanding 
  4. Should anything change with regard to the project scope and deliverables, the Project needs to have a good Change Management process to ensure the change is assessed and impacts understood including project viability

Project takes more time and cost than expected

The failure reason could have multiple causes. However some basics which can trip up the Project and thus should be a focus to get right are:
  1. Solid planning and estimating considering that you may need to break the plan into Stages due to Planner's Droop
  2. Continued monitoring and control of progress against plan with appropriate metrics taking remedial actions as necessary
  3. Analyse the Risks and ensure suitable mitigations / contingencies are in place Keep these under review.
  4. Remember that any Assumption you make in planning is a Risk so look to confirm these as soon as possible during Project execution
  5. Issues are likely to occur even in a well run Project so have a good process to manage them
  6. The Project can be derailed up by elements which are NOT delivered by the Project team but are essential for success. These are called External Dependencies and need careful management
  7. Always consider the human side of your Project Team. Do you have the elements in place to achieve a high performing project team?
  8. The Project can be derailed by uncontrolled change. Ensure that there is a clear definition of scope first and then instigate a good change control process to ensure that the impacts of a change are understood and agreed before it is accepted. Ultimately the owners need to understand that a constantly changing Project isn't going to get anywhere as illustrated by this cartoon
If Project scope is allowed to change freely - the rate of change will exceed the rate of progress

Delivery of Products which are not fit for purpose

If the Project spends a lot of time, effort and money to produce Products which are unusable, this is a clear failure. Consider:
  1. The Project Definition should include the clear end deliverable with acceptance / quality criteria
  2. You need to have a plan with regard to ensuring the quality of each product produced by the project. Consider whether you need to produce Product Descriptions for each product, this may or may not be required but should be a justified decision
  3. Ensure that you have a good configuration management strategy for the project products 

Conclusion

There are many reasons why Projects fail and there are essentials you need to get in place as a Project Manager. Of course, I haven't mentioned you much in this post and you are the linchpin for success. If you aren't doing your job correctly the Project has a high probability of failing. As well as good technical skills you need to have appropriate behaviour traits and spend your time on the right activities. With all these elements in place there is a good chance of success but never assume and keep monitoring, monitoring, monitoring!

Sunday, 1 May 2016

Famous Quotes and relevance for Project Managers

Do famous quotes have relevance for Project Managers and Project Teams? Can they can be an inspiration in certain situations? Yes, is my answer! Here is a selection I have picked with their relevance described.
Famous Quotes for Project Managers


Risk Management - Winston Churchill

One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half. Never run away from anything. Never! 
Churchill meant this in terms of Political Risk but it could apply to Project Risk. The way I have previously described it is Attack the Risks before the Risks Attack you!
Projects - Attack the Risks before the Risks Attack You

Alternatively, the Churchill quote reminds me of an important behavioural characteristic for Project Managers. As a PM you need to be prepared to stand your ground and not duck issues. I covered this and a number of other characteristics in this post.
Project Manager - If you don't stand for something you'll fall for anything

Issue Management - Charles F Kettering

A Problem well stated is a problem half solved
Kettering puts it very succinctly. Define your problem statement when you have an Issue and it helps focus the mind on the potential solutions. 

Dale Carnegie put it in a more descriptive manner:
Get the facts! Let's not even attempt to solve our problems without first collecting all the facts in an impartial manner
Have a look at my post on Issue Management

Human Aspects of Project Teams - various

Benjamin Disraeli
One of the hardest things in this world to do is to admit you are wrong. And nothing is more helpful in resolving a situation than its frank admission
 Benjamin Franklin
Arguing is a game that two can play at. But it is a strange game that neither opponent ever wins
It is worth keeping these quotations in mind when in the heat of arguments within the Project team or with other stakeholders

Dale Carnegie is worth considering with regard to team spirit and the importance of wanted to achieve as a team
You can't get anywhere in this world without wanting to do something 
When things get difficult within a Project and you are faced with the choice of a more risky approach versus holding back, remember this Lloyd Jones quotation:
The men who try to do something and fail are infinitely better than those who try to do nothing and succeed
Have a look at my post on Human side of Projects

Self-Motivation - Abraham Lincoln

If you are resolutely determined to make a lawyer of yourself, the thing is more than half done already ..... Always bear in mind that your own resolution to succeed is more important than any other one thing
As a Project Manager you need good self-motivation and always have in sight the ultimate goal. 

Read this post for other behavioural traits of a good Project Manager.

Coping with stress - Reinhold Niebuhr

God grant me the serenity to accept the things I cannot change, the courage to change the things I can and the wisdom to know the difference
As a Project Manager you need to cope with stressful situations at times and this quote is useful to remember. 

Read this post for more on coping with stress and worry.

Good Time Management - Henry Ford

It has been my observation that most people get ahead during the time that others waste
As a Project Manager you need good time management skills. I always start the day by working out the key things to achieve in the day. I try and address the things of most importance to the Project(s), not the easy things to tick off or the activities I prefer.

Personal and Project Lessons Learnt - Dale Carnegie

The difference between a successful person and a failure often lies in the fact that the successful man will profit by his mistakes and try again in a different way
Plutarch put it another way
To make no mistakes is not in the power of man; but from their errors and mistakes the wise and good learn wisdom for the future
I have found Organisations mixed in their approach to learning lessons from previous Projects. However, on a personal level, there is no excuse and I always make a point of considering what has gone well with Project execution, what less well and what I should aim to do differently next time.

Have a look at my post on Lessons Learnt where you will see another quote from philosopher George Santayana

Projects - Those who cannot remember the past are condemned to repeat it

Conclusions

I am always keen on "hooks" to remember key Project Management tips and techniques. I must admit to preferring proverbs and humour as my means of achieving this (see this post) but if are inspired by famous quotes then this could be best approach for you - as long as you remember to apply the tip or technique :-)

Wednesday, 20 April 2016

Why use Humour and Proverbs in your Projects?

I like to use humour and proverbs within my Projects for a number of reasons which I will expand on in this post but include:
  • to relieve tension
  • to show you are human
  • to act as a memory jogger
  • to aid communication
I will also mention the risks to be aware of when using humour which I have tried to convey in this cartoon.

Humour, Proverbs and Visual Images aid Project Manager Memory

Relieve tension?

Projects and Programmes are serious places, there is pressure to deliver within aggressive time-scales to achieve often important business cases within a temporary organisation thrust together for a number of months. Individuals can feel the pressure in different ways and sometimes this can boil over in heated words.

I find a bit of humour (even some of my poor efforts) can relieve tension whether in meetings with the team or within the pressure cooker of Project Board meetings.

Shows you are human?

As Project teams are normally built on a temporary basis you find yourself working with “strangers” and with the pressures, people can get certain perceptions of individuals. A joke or two shows that you are human and unless you offend (see risks below) can help build a better team spirit.

Acts as a memory jogger?

As a Project Manager you need to be able to think on your feet within meetings and discussions. There is reasonable scientific evidence that the use of humour, pictures and strap lines (proverbs) aids memory retention so that you can recall a key Project Management tip quickly.

Aids communication?

There are more than a few Projects where I have used proverbs to make a point and found them drip feed into team usage. So a strap line can aid communication I feel.  For example on one Project, when I heard team mates using the phrase “what isn't written hasn't been said”, I knew my message was getting across!

Projects - What isn't written hasn't been said

Risks

Project teams are often multinational these days and humour doesn't always translate well and there can be religious difficulties. So try and bear this in mind although I probably have made a few mistakes here so would like to apologise to current and former team mates, my intention is never to offend.

This is the message I am trying to convey in the main cartoon, you can use the humour to remember a key Project Management tip but you may decide not to use it in explanation!!

Conclusions

I believe there are many benefits to a bit of humour and proverbs within the cut and thrust of Project life and it probably doesn't do your health any harm either. But try and think before you open your mouth! 

Finally, if you want to see a little more on the scientific background to my memory retention claim or see a Project manual made entirely of my cartoons, have a look at this post.

Friday, 8 April 2016

A tour of PRINCE2 Principles - Tailor to suit the environment (7)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me finish with Principle 7 - Tailor to suit the environment.
PRINCE2 Principles

Principle 7 - Tailor to suit the environment

You need to realise that PRINCE2 was written for the UK Government. With deference to my colleagues working in government, sometimes they focus too much on the elegance of the process to the detriment of the outcome :-)

So my advice is always to look to tailor the methodology in line with this principle such as: 
  • cutting out some of the excessive process elements
  • adapting to the scale of project and the culture of the organisation
  • possibly changing some of the terminology?
Using an analogy, think of PRINCE2 as a tool-box for Project Managers in a similar vein to, say, a plumber has a tool-box. You wouldn't expect a plumber to use every tool in his/her box just because they are there, there is a level of adapting to the job at hand even though there are tools which are used on every job - the monkey wrench and especially the invoicing tool :-)

Excessive process points?

Here are some examples of PRINCE2 processes that I have tailored as they seem a bit "over the top" to me:
  • Change Management - I never log an Issue first before then logging the Request for Change. I have a much simpler approach which I detailed in this post.
  • 99 times out of 100 the "Starting up" and "Initiation" processes become one process - Initiation!
  • While some of the Management Products proposed are good in the principles behind them (and it is worth agreeing the subject matter as necessary), I have rarely produced a lot of them. Let me walk through these one by one:

  1. Acceptance Criteria - not a separate Product, include within the Project Definition
  2. Business Case - yes, plan to produce this - see this post and Principle 1
  3. Checkpoint Report - replace with Team meetings or "One to One" meetings with key team leads in the majority of cases. It may be useful for third parties or where a piece of work has been defined as a Work Package
  4. Communications Plan - yes and no! It isn't a separate Product but the spirit is included in a Stakeholder Map you should produce - see this post
  5. Configuration Item Record - most of the content proposed goes into a Product I produced called a Quality Plan, see this post
  6. Configuration Management Plan - rarely documented unless something new is being defined - see this post
  7. Daily Log - I walk everywhere with my A4 ring bound pad titled my "Day Book". I use it for time management and logging meetings and thoughts
  8. End Project Report - yes, this is your exit route to say the Project is complete although I normally call it the Project Closure Report - see this post
  9. End Stage Report - I have rarely produced (I remember doing so for a Government client!). This information I tend to share with the Project Board & Sponsor through a Project Board Pack - see this post
  10. Exception Report - I hope this isn't needed! But if you hit problems, communicate early and not via a report or email!! You may then to produce a revised plan, I prefer to call it a Recovery Plan than Exception Report, again making PRINCE2 a little more understandable to the non expert
  11. Follow-on Action Recommendations - I have never produced a separate Product although the detail should be covered in the Project Closure Report, see above
  12. Highlight Report - yes, this is one to produce, I suggest weekly. Again I tend to call it a Status Report - see this post
  13. Issue Log - yes, although normally part of a combined RAID Log - see this post
  14. Lessons Learnt Log - I have never created such a Log but I do have a simple text file on my desktop which I can jot thoughts
  15. Lessons Learnt Report - yes, either separately or as a section in your Project Closure Report - see this post
  16. Off Specification - I have never produced as part of Issue Management. Each Product should go through a quality assurance process and then be baselined. That doesn't mean that there aren't residual problems but these should be minimised.
  17. Post Project Review Plan - The spirit of this Product is what I call the Benefit Realisation Plan (again I prefer my title, it says more about the purpose) - see this post
  18. Product Breakdown Structure - I have rarely produced this although it could be useful in some circumstances and the principle of Product based planning (see Principle 6) is an excellent one - see this post
  19. Product Check-list - I like to produce this in Excel with a few other columns to form what I call a Product Quality Plan - see this post
  20. Product Description - a good idea but in 80% of cases you can achieve the aims in a better way I feel. For 20% of cases it may be worth doing as described by PRINCE2 - see this post
  21. Product Flow Diagram - this can be useful sometimes when you haven't "been there & done the Project execution before" - see this post
  22. Project Approach - this should form part of the Project Definition
  23. Project Brief - the only time I have seen as a separate Product is in Government clients. I include the content in the Project Definition
  24. Project Initiation Document - yes, very useful, the contract between the Project Owner and the Project Team. But I call it the Project Definition
  25. Project Mandate - I can never recall being handed one of these! I've afraid, life is not normally that straight forward and sometimes you need to go and seek the all important Owner of the Project, who I call the Sponsor - see this post
  26. Project Plan - quite useful, we will have one of those! - see this post
  27. Project Quality Plan - a section in the Project Initiation Document above
  28. Quality Log - I can't say I have ever had one of these although as I have said I am very keen on a Product Quality Plan - see this post
  29. Request for Change - in most Projects I will accept an RFC by an email to me explaining sufficient detail. On some Projects it is worth having a form to make the requester think a bit - see this post
  30. Risk Log - yes, although normally part of a combined RAID Log - see this post
  31. Stage Plan - in rare occasions I have produced a separate Stage Plan, often I choose to have as a section in the Project Definition which is refreshed when moving from one Stage to another
  32. Work Package - this can be useful, especially when dealing with off site third parties - see this post

Adapting to the scale of project and organisational culture

The management of the Project using PRINCE2 is a necessary evil but should be scaled to the size of the Project. If the technical effort of the project is 100 man days you don't really want to be spending 300 days effort on the management!

Some organisations love reams of paperwork, some seem to use little documentation. One of the key documents it is always worth having is the Project Definition (PID). In some organisations these are sizeable Word documents but for smaller projects or "anti-document" organisations, I have a PowerPoint template with the "essence of the definition" and nothing more. This is quicker to produce and more easily digested by stakeholders.

In terms of ownership, for a major project with a big investment or critical outcomes, a good well formed Project Board with various participants is useful to govern ensuring good stakeholder representation. But for many organisations or smaller projects, a single Sponsor is quite sufficient.

Changes of terminology

It may seem strange for me to suggest changes of terminology as one of the benefits of a methodology is a standard set of terms. However, in my experience, many of the people involved in Projects aren't steeped in PRINCE2 terminology and so there are a few examples of where I change things to (I hope) aid understanding:
  • the Owner of the Project in PRINCE2 is called the Project Executive. I prefer to use the term Sponsor as I feel it better reflects the role and is easier to understand
  • the key "contract" between the Sponsor and the Project team which defines the Project is called the Project Initiation Document by PRINCE2. I prefer the term Project Definition as once again I believe it better describes the Product
  • some of the other PRINCE2 Management Products I give different names, see above
Beware of too much terminology and always be prepared to explain concepts to people rather than just quote PRINCE2 terms all the time. I went into this further in a post about helping the Sponsor in particular.

Other PRINCE2 Principles

The other PRINCE2 Principles are:
  1. Business Justification - continuously throughout the Project execution
  2. Learn from Experience - from previous Projects
  3. Defined Roles and Responsibilities - so there is clear understanding of who is responsible for what
  4. Manage by Stages - breaking down the Project execution into manageable chunks with gate reviews to move from one to the next
  5. Manage by Exception - once plans are in place with the owner, no news is good news
  6. Focus on Products - a focus on what is being produced rather than activities is beneficial
  7. Tailor to suit the environment - this one!

Saturday, 2 April 2016

A tour of PRINCE2 Principles - Focus on Products (6)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me continue with Principle 6 - Focus on Products.
PRINCE2 Principles

Principle 6 - Focus on Products

This key principle implores that before looking at what activities are required to deliver the Project, the focus should be on Products i.e. Artifacts:
  1. The most important Product is the final one(s) delivered by the Project
  2. To achieve the final Product there are various intermediate Products that need to be produced - both Technical and Management
  3. Technical Products will be different for differing types of Project types and Project life-cyles and are concerned with the real journey to the final Product. So if the Project is producing something, you may need some intermediate Products defining the Requirements, the Design, any Testing etc
  4. Management Products are concerned with the running of the Project itself. PRINCE2 defines many of these such as the Project Initiation Document, Stage Plan, Business Case etc
So in English grammar a Product is a noun not a verb. Put more simply you should be able to touch most Products!

Planning

So PRINCE2 recommends that you commence your planning by considering the Products to be delivered. It suggests a number of techniques to adopt including a Product Breakdown Diagram (not Work Breakdown!) and Product Flow Diagram. For more detail, have a read of the post on Product Based Planning.

Is the Product properly understood?

PRINCE2 also suggests you spend effort defining in some detail, the characteristics of each Product. While this is a powerful technique, I look to short cut in a number of ways which I cover in the post on Product Descriptions.

This should also cover how we assure that the Product is of "fit for purpose" quality. For intermediate Products I prefer to address this via a Quality Plan which I covered in this post. For the final Product(s), this is so important that the Quality acceptance criteria should be covered in the Project Definition.

Don't forget Management Products!

PRINCE2 is quite "heavy" in terms of the Management Products it recommends and this is an area where some tailoring can be useful, see Principle 7

Other PRINCE2 Principles

The other PRINCE2 Principles are:
  1. Business Justification - continuously throughout the Project execution
  2. Learn from Experience - from previous Projects
  3. Defined Roles and Responsibilities - so there is clear understanding of who is responsible for what
  4. Manage by Stages - breaking down the Project execution into manageable chunks with gate reviews to move from one to the next
  5. Manage by Exception - once plans are in place with the owner, no news is good news
  6. Focus on Products - this one!
  7. Tailor to suit the environment - the methodology should be tailored to the environment, organisational culture, size, complexity and risks

Monday, 28 March 2016

A tour of PRINCE2 Principles - Manage by Exception (5)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me continue with Principle 5 - Manage by Exception.
PRINCE2 Principles

Principle 5 - Manage by Exception

Although PRINCE2 really promotes the role of Project Owner (see Principle 3), it recognises that a Project Board made up of senior stakeholders probably don't have time for day to day involvement. So this principle is about setting the framework in terms of a "contract" between the Owner and the Project Manager who has freedom to operate within the terms and tolerances defined. The contract is what I call I like to call the Project Definition (PRINCE2 calls it the Project Initiation Document) or indeed the Stage Plan which sits under this to manage a particular Stage. Have a read of my post on Project Definition which speaks of a Kipling poem "I keep seven honest serving men...."

The Project Board members can therefore reasonably assume, within the framework of the relevant agreed plan that No news is (broadly) good news.

Despite this principle I always look to keep the Project Board up to date on execution status (including hot issues, risks, change requests, spend against budget etc) by:
  1. Drafting a weekly status report and issuing this to the Project Board members. This is a one way communication but the Sponsor / Board members can come back if they read and have queries. Have a read of this post on Status Reporting for more details.
  2. Having a Project Board meeting around once a month. This forces the Board members to keep in touch with execution status as well as being a forum for discussion of points the Project Manager wishes to raise requesting guidance. Have a read of this post on Project Board meeting preparation for more details.
However, if you a forecasting to be outside the tolerances set in Project Definition or Stage Plan you need to escalate to your owning Board. Other reasons to escalate include a high impact Issue which you cannot resolve within the Project team. Have a read of this post on why, when and how to escalate for more details.

Finally, sometimes a Project Manager can adopt the principle to reduce day to day involvement in some task areas. This is when a piece of work is packaged up carefully into a Work Package and given to a third party or internal team manager. When defining the Work Package you define the tolerances and reporting requirements so this principle comes into play. Have a read of this post on Work Package principles.

Other PRINCE2 Principles

The other PRINCE2 Principles are:
  1. Business Justification - continuously throughout the Project execution
  2. Learn from Experience - from previous Projects
  3. Defined Roles and Responsibilities - so there is clear understanding of who is responsible for what
  4. Manage by Stages - breaking down the Project execution into manageable chunks with gate reviews to move from one to the next
  5. Manage by Exception - this one!
  6. Focus on Products - a focus on what is being produced rather than activities is beneficial
  7. Tailor to suit the environment - the methodology should be tailored to the environment, organisational culture, size, complexity and risks

Wednesday, 23 March 2016

A tour of PRINCE2 Principles - Manage by Stages (4)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me continue with Principle 4 - Manage by Stages.
PRINCE2 Principles

Principle 4 - Manage by Stages

This is a powerful principle of PRINCE2. The first part of the principle is that PlanningEstimating and thus Budgeting for a whole Project is difficult to a reasonable degree of accuracy. As I put it in a post, you are likely to suffer from Planner's droop! as the accuracy of plans often drops with time. So PRINCE2 offers the concept of the Stage. So you have a firm plan and budget for the current stage and a more outline plan and budget for the remainder of the project.

The second part of the principle is that the end of a Stage forces a formal checkpoint or preferably a Gate where the firm plan and budget for the next Stage is presented and ideally the Business Case is reassessed and also presented. In the best organisations this assessment is done with participation from outside the Project owners to ensure impartiality. The approach forces one or several check(s) part way through on the Project viability in line with PRINCE2 Principle 1. Have a read of my post on Gated reviews.

Where to select the Stage boundary? Look for a point in the project life-cycle where more certainty on estimates can be provided and before any big commitment to costs or rapid increase in burn rate. In an IT Project utilising a waterfall style approach, a Stage covering Analysis and Design is a good choice so a Stage gated review happens before the commencement of Build / Construction.

Lastly, don't forget that PRINCE2 mandates a special Stage called Initiation where the brief is fully understood, Business Case is extended or created, plans (including use of Stages), estimates, budgets etc are established. I wrote a post covering a check-list for Initiation which is worth a read.

Other PRINCE2 Principles

The other PRINCE2 Principles are:
  1. Business Justification - continuously throughout the Project execution
  2. Learn from Experience - from previous Projects
  3. Defined Roles and Responsibilities - so there is clear understanding of who is responsible for what
  4. Manage by Stages - this one!
  5. Manage by Exception - once plans are in place with the owner, no news is good news
  6. Focus on Products - a focus on what is being produced rather than activities is beneficial
  7. Tailor to suit the environment - the methodology should be tailored to the environment, organisational culture, size, complexity and risks

Tuesday, 15 March 2016

A tour of PRINCE2 Principles - Defined Roles and Responsibilities (3)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me continue with Principle 3 - Defined Roles and Responsibilities.
PRINCE2 Principles

Principle 3 - Defined Roles and Responsibilities

The third principles is that everybody concerned in the Project should understand their role(s) & responsibilities and how they relate to each other.

For me, the key words to expand on this principle are Ownership, Accountability, Management and Organisation.

Owning Roles

Every Project needs ownership and the owner isn't the Project Manager (PM), the PM just runs the project day to day on behalf of the owner. Committees where every person has a vote which are counted, are not efficient organisations (sorry Parliaments everywhere) so there needs to be one accountable person. PRINCE2 calls this person the Executive, I prefer a word which I believe is easier to understand, the Sponsor. PRINCE2 recognises there are key Stakeholder groups and suggests key representatives to help the Sponsor make his decisions. The Sponsor and these stakeholder representatives are called the Project Board. Have a read of my post on these roles.

Project Team Roles

A good organisational structure and understood roles & responsibilities for your Project Team is also important. If everyone on the team knows what they need to contribute and what other team members are responsible for, you have a solid foundation for success. Project teams often cross traditional line management structures which adds added complexity - matrix management!

Have a read of three posts - one on Project Teams structuresone on human factors and one on the behaviour characteristics of an important role in the Project team - the Project Manager.

Other PRINCE2 Principles

The other PRINCE2 Principles are:
  1. Business Justification - continuously throughout the Project execution
  2. Learn from Experience - from previous Projects
  3. Defined Roles and Responsibilities - this one!
  4. Manage by Stages - breaking down the Project execution into manageable chunks with gate reviews to move from one to the next
  5. Manage by Exception - once plans are in place with the owner, no news is good news
  6. Focus on Products - a focus on what is being produced rather than activities is beneficial
  7. Tailor to suit the environment - the methodology should be tailored to the environment, organisational culture, size, complexity and risks

Friday, 11 March 2016

A tour of PRINCE2 Principles - Learn from Experience (2)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me continue with Principle 2 - Learn from Experience.
PRINCE2 Principles

Principle 2 - Learn from Experience

The second principle is that Project execution is improved by previous Project learnings. I remember this through a Proverb from philosopher George Santayana who stated "Those who cannot remember the past are condemned to repeat it".

This is broken into 3 parts in my mind:
  1. The Project Manager (PM) should bring his / her personal learnings to bear in Project execution
  2. The Project Manager should seek organisational learnings from previous Project executions at the organisation in question
  3. The Project Manager should deliver lessons learnt from the current Project for the benefit of future Projects.
For #1, I encourage all PMs to always take learnings out of every Project they run. Many organisations, if recruiting externally, like to look for a PM with a track record in the particular project domain for this reason. #2 is a bold aim but I haven't personally seen organisations succeeding by achieving a usable database for other PMs to find key lessons to apply. However, I have got some benefit from speaking with individuals previously involved in the domain area. Lastly, you don't get #1 and #2 without #3 so please plan for this. Have a read of my post on lessons learnt.

My final point to make about lessons is that often the focus is on the negatives, things that didn't go too well. You should also look for positive lessons i.e. best practices which may apply to your organisation or project domain.

Other PRINCE2 Principles

The other PRINCE2 Principles are:
  1. Business Justification - continuously throughout the Project execution
  2. Learn from Experience - this one!
  3. Defined Roles and Responsibilities - so there is clear understanding of who is responsible for what
  4. Manage by Stages - breaking down the Project execution into manageable chunks with gate reviews to move from one to the next
  5. Manage by Exception - once plans are in place with the owner, no news is good news
  6. Focus on Products - a focus on what is being produced rather than activities is beneficial
  7. Tailor to suit the environment - the methodology should be tailored to the environment, organisational culture, size, complexity and risks

Friday, 4 March 2016

A tour of PRINCE2 Principles - Business Justification (1)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me start with Principle 1 - Business Justification.
PRINCE2 Principles

Principle 1 - Business Justification

This principle, which is an excellent one in my view, is all about there being a viable Business Case under review throughout the Project life cycle.

Firstly, an outline Business Case should be used to determine whether to actually start a particular Project as most organisations are constrained by available funds and/or in-house resources and so should choose the Project(s) which provide the maximum benefits or align to the organisational Business Plan. As I stated in a post on the subject of the Business Case, Do the Right Project before Do the Project Right

At this point, I want to be clear on what constitutes a successful Project. For me, there are two dimensions. One for the Project Team to own is about Do the Project (Delivery) Right. The other one for the Project Owner is about delivery of the stated benefits of the Project. I detailed this in a post on Project success.

So in an ideal world, the Project Manager when first engaged:
  • is handed an outline Business Case
  • is told who the Owner of the Project is - I prefer to call this role the Sponsor (PRINCE2 calls it the Executive) - an example of me tailoring the method - see Principle 7 :-)
Sadly, we don't often live in an ideal world! If no Sponsor has been defined, you need to find one. Remember Shakespeare and the quote O Sponsor, Sponsor! wherefore art thou Sponsor? as per my post on the subject.

If no Business Case has been produced, this should be a focus during Project Initiation. Even if you, as PM, have been handed an outline Business Case, this should be refreshed during Initiation as the accuracy of the Project costs should be improved by the planning and estimating that takes place. The benefits side of the Business Case will need discussion and agreement by the Sponsor as, even though the PM may assist the Sponsor in production of the document and supporting models, accountability for benefits lies with the Sponsor.

The key point about this principle is that having established the Business Case and thus agreed that the Project is viable to commence, the Business Case should NOT be thrown in a cupboard never to be seen again. It should be kept under review during the Project execution to see whether:
  • the Business Case is no longer valid (so should the Project be stopped?)
  • the Business Case is enhanced or 
  • that the Business Case has stayed broadly the same
Many Business Cases can be impacted by things external to the organisation so if this is the case, someone (Sponsor?) should be keeping their eye on the external environment in which the Project will end up delivering. For example, around 2009, did someone in the Nokia organisation assess the impact of the market rise of the Smart Phone on the Business Case for the latest Nokia phone being developed?

The problem with this lofty goal is that there is usually something "more important" to do with regard to project execution than periodically review the Business Case. But PRINCE2 suggests an answer - Principle 4 recommends management by Stages and formal Gate reviews between Stages. I have seen this approach forced by a few organisations that I have worked with. In one such organisation, at least two stages had to be built into plans and firm funding was only provided for the current stage. At the Stage Gate review, the Project had to refresh and represent the Project Business Case as part of securing the funds for the next Stage. This forced the periodic focus on Business Case in line with this principle. Have a read of PRINCE2 Principle 4 post for links to related Better Sheepdog posts when it is posted in a couple of weeks.

Lastly I aim, if possible, to go one step further with regard to this principle and look to plan for creation of a product / artifact called a Benefit Realisation Plan which details far more about the benefits than is traditionally seen in a Business Case such as:
  • each low level benefit clearly articulated including levels expected over time etc?
  • who is accountable for delivery of each low level benefit?
  • how it will be measured?
  • who will undertake the measurement
  • who will police the benefit measurement - an organisational PMO is quite useful in this regard as it lives past the close-down of individual projects

Other PRINCE2 Principles

The PRINCE2 Principles are:
  1. Business Justification - this one!
  2. Learn from Experience - from previous Projects
  3. Defined Roles and Responsibilities - so there is clear understanding of who is responsible for what
  4. Manage by Stages - breaking down the Project execution into manageable chunks with gate reviews to move from one to the next
  5. Manage by Exception - once plans are in place with the owner, no news is good news
  6. Focus on Products - a focus on what is being produced rather than activities is beneficial
  7. Tailor to suit the environment - the methodology should be tailored to the environment, organisational culture, size, complexity and risks

Twitter Delicious Facebook Digg Stumbleupon Favorites More