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

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

Twitter Delicious Facebook Digg Stumbleupon Favorites More