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

Friday, 24 July 2015

Product Descriptions - do you need?

PRINCE2 has an excellent concept of Product Descriptions (PD) yet I, like many Project Managers, rarely produce them as part of Project execution. This may seem a contradiction but in most cases the objectives of the PD can be achieved by either other parts of your overall Project approach or in other ways that minimises the effort required. Where an alternative doesn't exist it is worth using the technique. Let me explain what I mean.
Project Product Descriptions

What is a Product Description (PD)?

Firstly a reminder what is a Product Description (PD)? A fundamental principle of PRINCE2 is Product Based Planning with a Product being a deliverable (either an intermediate one or the final one) and PRINCE2 says that for each Product you should produce a PD covering:
  1. ID/Version - for configuration management
  2. Title / Purpose
  3. Composition - what are the "parts" which go to make up this Product
  4. Derivation - what other Products which are needed to achieve this Product (e.g. from Project Product Flow Diagram or maybe an external dependency)
  5. Format / Presentation - e.g. spreadsheet
  6. Allocated to - person, group or skills required to produce
  7. Quality criteria / tolerance / method / skills

Where else is the PD information?

In many projects most of your intermediate products are documents and using the 80/20 rule, I will focus here initially. Working through the 7 points above:
  • Items #1 is only needed if you actually produce a PD!
  • Items #2 and #7 are effectively covered in the Quality Plan I will produce. 
  • Item #4 is often self evidence from a defined lifecycle or previous projects of a similar nature. For example, in IT System Development projects I often run, this would be a generic or organisation specific SDLC
  • Item #6 needs to be identified during Planning
  • Which leaves Items #3 and #5. In an ideal world the organisation has a Quality Management System containing document templates, best practice example documents, guidelines on approach to production and hopefully guidance of the quality processes (Item #7). Where this isn't the case, I will focus attention here to basically produce and agree a skeleton of the content of the document as early as possible - chapters, sections, diagrams needed etc. This both gives a better basis for detailed estimating and basically defines this key aspect of the PD which isn't defined elsewhere
So there you have it, there is no need to produce PDs in many cases but you still have all the good principles behind this PRINCE2 concept in place.

The ultimate Product for a Project is the end deliverable and PRINCE2 says this is an early PD to produce. Once again, the principle is excellent but I don't usually produce as I want all this information to be in the Project Definition so it is reviewed and approved by the Project Owner i.e. Sponsor or full Project Board.

Look out for the exceptions and produce PDs

Be on the lookout where a Product doesn't have PD defined elsewhere and plan to produce a PD document as early as possible in your Project life-cycle. It gains consensus on what the Product is, helps support detailed bottom up estimates / resourcing and how to ensure the Product is of suitable quality.

Friday, 17 July 2015

Difficult meetings? Try Six thinking hats

Do you have problems in meetings because some people always seem to take the same attitude, often negative? Does emotion overcome logic and information content in debates? If so, you may want to try using the Six Thinking Hats approach proposed many years ago by Edward de Bono.

Basic idea and approach

To encourage meeting participants to separate their thinking, you have six coloured hats on the meeting table and when people want to speak they need to wear one of the hats to "focus" thinking. By switching hats you can re-direct your thinking which becomes more definite. Therefore the discussion becomes more focused and productive.

The essence of each hat is:
  • White - pure facts, figures and information. Either information introduced into the meeting or a request for some.
  • Red - expressing emotions & feelings; also hunches
  • Black - devil's advocate, negative judgement, why it will not work
  • Yellow - "sunshine", optimism, positive, opportunities, benefits
  • Green - fertile, creative, new ideas, 
  • Blue - the conductor (cool & control), used to ensure the process is running correctly 

Does it work?

I must admit that I haven't used this technique for over a decade now but I keep in my armoury for circumstances where meetings can't be made productive using more traditional means! For example, if the mood (or particular participants) is particularly bleak in meeting after meeting I believe this can enable you to break out of the situation. It isn't a quick fix as you need to persevere with the approach over several meetings before it becomes more natural but can help force some more positive thinking. Try and encourage more yellow and green hat usage to start with in the meeting.

So if you want to give it a try, go buy 6 cheap party hats, mark the colours in some way (it doesn't have to be fancy), have a one page briefing sheet on the table and off you go. 

If you want to read more about this technique buy the book or look at the website.

Practical challenge with Project teams in different sites

In my (IT focused) experience, Project teams are no longer located in the same building and many meetings have participants joining remotely, typically on voice only. This brings an additional barrier to the success of this technique as the visual act of picking up a hat from the table and wearing it, is important in my experience. All I can suggest that remote participants have to announce the colour of the hat before speaking or you gain access to video conferencing facilities (but don't forget that you need hats in each location).

Other tips on running meetings

You might want to search the Blog (or select the "Meeting" tag) for other tips from me on improving Meetings such as applying Work Package principles from which it is worth a reprise of this cartoon :-)

Project Meeting Warm-Up

Sunday, 5 July 2015

Why, when and how to escalate to your Project owners?

As a Project Manager you may need to escalate to your Project owner (Sponsor or Board) on hopefully rare occasions during execution of the project but at an appropriate time in relation to the situation faced. "Escalate" in this context means notify and ask for assistance / make a decision. This post takes you through the situations when this may be necessary and when/how to go about it.
Project Escalation to Sponsor and Board

Principle of Management by Exception

Firstly I should take you through an important principle in your interaction with your Sponsor or Board. Once you have an agreed Project Definition in place the Sponsor should be able to assume "no news is good news" and that the Project Manager will make contact if this is not the case. This doesn't mean that there is no communication. 
  1. As part of your Stakeholder Analysis you should agree the communication frequency and approach. Personally I like a weekly status report which is available for anyone to read.
  2. I recommend that you establish a schedule of regular formal Project review meetings (i.e. Project Board meetings) with your Project owner. These are used as a formal status check and to make decisions in line with the Project Plan.

When - i.e. Escalation timing - not too soon, not too late

Choosing when to escalate is a judgement call and it isn't an easy decision. Too late and the Project may be left burning money going nowhere. Too soon and the Project Manager may be seen to be a poor manager by not attempting to resolve within the team first. 

To take the analogy in the cartoon, escalating when the ship has actually run aground is far too late!! You should escalate when you are heading firmly for rocks and need to agree a new course or resolve some critical issue with the assistance of your owners.

Why Escalate?

You should escalate if:
  • you are forecasting that the project will be outside the Time, Cost, Quality/Scope or other key success criteria agreed for the Project or Stage of the Project
  • you have a critical Project issue that needs assistance from your project owners
As part of your Monitoring and Control activities you should be regularly forecasting status against the key success criteria agreed with the Project owners via the Project Definition. If, for example, a key "go live" milestone is now forecast outside the agreed target (including any tolerance) or costs are forecast to exceed the agreed budget, you need to escalate. Note that in PRINCE2 this situation is actually called "going into Exception" in line with the principle of management by exception!

Sometimes you have a critical Issue which you need project owner assistance in resolving. You should make every attempt at resolving this within the team using techniques such as Project Punches if required but sometimes you have no choice but to involve the project owners. An example might be a "difficult stakeholder" outside the project team where the Sponsor or Board members have greater influence.

How to escalate?

Escalation is almost always bad news for the project owners and you need to consider the best way to deliver some bad news from a good communication and human standpoint. I recommend picking up the phone.....
Projects - The best way to communicate bad news to your Sponsor

Be very clear about the reason, what your next steps are and what assistance you require. So, in summary the key elements of an example call content might be "Sorry Steve, we have had continued major environmental issues which have delayed our testing phase and at the moment I don't believe we can go live as planned. I am looking at recovery options and will get back to you with these by Thursday for you to make a decision"

You should back up your call with some sort of email report - the Exception Report in PRINCE2 terms. 

Follow-up after the escalation

You should agree the follow-up actions and timetable with your Sponsor. This may mean that you as Project Manager own the action(s) e.g. to produce options on a recovery plan or that the Sponsor or even Senior User owns the action(s) e.g. to get an external stakeholder back on board and supportive of project execution. 

Don't forget that the viability of the Project should be assessed in certain circumstances as an "Exception" may impact the agreed Business Case. This should be discussed with the Sponsor and in the ultimate case, this may cause the Project to be stopped.

Conclusion

As a Project Manager you need to understand the circumstances where you need to escalate to your Sponsor or Governance Board, the owners of the Project. Using the principle of management by exception these are when the agreed Project or Stage success criteria are forecast to be exceeded or a serious Issue needs owner support to resolve. You need to escalate at an appropriate time in advance of Project execution being totally halted and do so in an appropriate human way but ensure that the actions following on from the escalation are agreed.

Twitter Delicious Facebook Digg Stumbleupon Favorites More