Implementing project management quietly

Many training organisations expect you to return to your workplace as an evangelist, singing the praises of project management, and generally changing the world.
I just don’t believe it…..
Of course sometimes that can happen, but in many in-house courses people are sent to the training by a boss who just wants to give team members some exposure to training, and really doesn’t want his/her world changed at the end of the event.
Well, OK. If your boss is one of these then we need to think carefully about how to implement some of the training so that you get some benefit without the boss being too challenged.
We need to separate the principles of project management from the physical implementation. Of course we all hope that our boss wants us to start writing Project Charters, but if he/she will find it hard to take then you must adopt the ‘softly softly, approach.
Don’t push the formal project charter, with its words like ‘business objectives’, ‘scope’, and so on straight in the boss’s face. Produce your charter without the headings, and keep the jargon to a minimum.
Don’t then spoil it by insisting that the boss should check and sign off your document. Say something like ‘just in case I didn’t understand what you wanted I wrote it down – have a look at it will you, and see if I’m on the right track’.
This equates exactly to a charter sign off, but without the in-your-face PMBoK jargon.
This might work, when a more direct approach will not work. If the boss begins to understand your approach then you can make it more formal, step by step.
Remember the objective is to implement project management principles, and this might not happen in one big push right after the training.
Be prepared to win slowly.

© Mike Watson 2012

Agile projects – the key roles

There are several key roles in an Agile project, but I want to focus on the role of the product owner, or the ‘key user’, or ‘champion’. This is the sponsor’s representative embedded fulltime in the project team, and must bring three vital attributes to the project, as follows:
1. A thorough practical understanding of how the business processes work at the moment
2. A thorough understanding of the desired state in the business area (not HOW the project will solve the problems, but a clear view of the desired business outcomes)
3. Authority to accept or reject project deliverables on the spot, without recourse to focus groups, acceptance meetings and so on.
Unfortunately what these attributes describe is someone who is vital to the current day-to-day operation of our customer department; someone who may be very difficult to release full-time (and it HAS to be full-time).
This practical resourcing issue can be a sticking-point for many Agile projects, and the prospective Agile project manager must be adamant that without this commitment the project must not attempt to use the Agile approach.
This is another reason why the Agile project will benefit from a short education session up-front.

© Mike Watson 2012

Agile – are we ALL serious about this?

The idea of Agile Project Management is very seductive for senior management.
It promises faster delivery of beneficial outcomes. Wow – who would turn down an offer like this?
However, everything has its price, and in Agile the price is not necessarily a financial one, but a management philosophy one.
For Agile PM to work the senior management (on both sides of the project – the customer/sponsor as well as the project management team) must understand the key feature that if the target date is fixed then the SCOPE of Delivery will slip!
And it really will reduce as the project runs; this is not a theoretical nicety, it is a fact of Agile Project Management. If the nature of the project deliverable is that its scope cannot be reduced then maybe Agile is not the way forward, but a waterfall approach may be more effective (Agile is not a universal solution to project problems).
The up-front acceptance of this mandatory philosophical approach is essential. Most Agile projects will start with some sort of education session, to make sure that all the key players are on board with the implications of the approach.
Now of course everyone will say that they ARE on board, but true commitment can be more difficult to establish. One way to start this process is to add into the up-front discussions the specification of the roles of the key players and to start the process of prioritisation of requirements. This will sort out the chickens from the pigs (egg and bacon breakfast – the pig is committed but the chicken merely involved).
More of these in later posts.

© Mike Watson 2012

Things they don’t tell you on training courses, #1

I am constantly amazed how many people with better memories than mine (OK, that’s just about everybody) ask me when certain things happened on our project.
Nowadays, despite the plethora of software aids, no one seems to keep a diary. Maybe if someone were to write a sexy app for the iPad then more people would keep a diary, but actually all you need is a word processor such as non-sexy MS Word and the determination to keep it going.
Actually my diary is a simple Word document written almost as a stream of consciousness, but I am careful to break up the stream with dates (and sometimes times).
I note everything that happens beyond simple task completion. I also leave minutes of meetings to the experts, but anything else is fair game.
By ‘anything else’ I include all personnel matters, deliveries of hardware and software, visits by sponsors and customers, decisions made or rejected, achievement of milestones and deliverables, and so on.
Some of these things are obviously included in project plans and progress reports, but many are not, and to have a record of all activity can be very useful.
I spend just a few minutes every day recording what happened. My best time for this is early the next morning, but I can see that a better time is at the end of each day. However, I am often so desperate to ‘get out of this place’ that I have developed the morning habit.
And that leads to many of my younger and fitter colleagues relying on my diary……

© Mike Watson 2012

Different cultures use time differently

There was a firm belief that the 2004 Olympics in Athens would never happen (in fact the team from Sydney 2000 was put on emergency standby), because to some eyes the Olympics project was far behind schedule, with a huge amount to do in very little time.

However, the games were a great success, partly because of the way in which Greeks (and it’s not just Greeks) approach time management.

In simple terms there are two extremes of how we use time. Some cultures are by nature ‘polychronic’ (meaning preferring to juggle many tasks and responsibilities at once) and some are, by nature, ‘monochronic’ (meaning preferring to focus on one thing at a time).

The Greek Olympics project team were polychronic, and many of the observers from the IOC were monochronic, and herein lies a warning for project managers of multi-cultural teams.

In terms of how you might view your project team members please be very careful to understand two things: your own cultural preference for time usage and that of the individual team members. Just because someone doesn’t approach tasks in the way you would doesn’t necessarily make them wrong, and if you try to force your way of working on someone else it may cause more problems than it is worth.

Get these differences out into the open. Make sure that ALL team members (you included) understand the theories here (you can study the work of Edward T Hall if you wish), and how a mixed team needs to work with the differences, not against them. You can have an extremely productive (and fun) kick-off meeting where these differences can be identified by various exercises and ice-breakers (check Google).

Remember a team derives its strengths from diversity, not cloning.

© Mike Watson 2012

Where did it go?

I sat at the lunch table in the world’s leader in database technology and listened to a project manager say something astounding.

He said ‘I love my job’. OK, that’s not astounding, but what came next was:

‘I really don’t know what will happen from one day to the next – it is so exciting’.

Now, I would have sacked this guy! I expect my project managers to know exactly what will come next at least 3 days out of every 5.

What really puzzles me, though, is just how many project managers actually know just where their time does go. I have met many project managers who complain that they don’t have enough hours in the day, but I have met very few PMs who know where the hours go.

I’m not necessarily recommending time sheets, but think about other professionals such as lawyers. When you walk into their office the time clock goes on! Yes of course this is for billing purposes, but it also provides them with facts and figures about where every hour goes, not just billable hours.

So, maybe for a couple of weeks try keeping a personal timesheet. You may be surprised at the results. More to the point, your boss may be surprised! How can you ask for assistance when you cannot prove who/what eats away at your time?

You may also find that you deal with many time-consuming issues from just one source. Is this telling you about a breakdown in your communications plan?

Don’t be a slave to the time recording, but it might just help you leave the office at a reasonable time once or twice!

 

© Mike Watson 2012

Getting people to present at your Kick-Off Meeting

The responsibility for having a kick-off meeting falls to the project manager, but he/she does not have to do all the presenting at the meeting. It can be truly impressive to demonstrate just how well-organised the project is by involving other speakers. These can include:
1. A technical team member who will be working on new technology, or in an interesting environment. The enthusiasm that such a person can transmit can be contagious, but be careful; not all techies are willing to do ‘public speaking’. Don’t force someone to do it when they really don’t want to do it; it will look vindictive!
2. The sponsor or a business user. Sometimes the techies on the team may have no real understanding of how what they produce will affect the lives of the end users. The danger with this is that the sponsor might just ramble on, taking too much time, drifting across your own material, and destroying the one thing you were striving for (the impression of ‘being organised’). Be quite specific with the sponsor, and describe the scope and timescale of his/her contribution.
3. One or more ‘stage managers’; a stage manager (sometimes called sub-project manager, or work stream manager, or work package manager) is someone who takes responsibility for the day-to-day aspects of one part of the project. If the project manager introduces them, and they spend a few minutes describing their roles in managing part of the project then this sends a powerful message that ‘this project is well organised’.
If you can get the members of the meeting to think ‘wow, this looks good’, then you have won.

© Mike Watson 2012

When is the best time for a kick-off meeting?

Obviously we should have a kick-off meeting at the start of the project…..
The difficulty comes with exactly when is the start. If we hold it after the Charter has been signed off then it can be seen that the project exists, but for some people the opportunity to contribute to the charter has been lost.
Try to hold the kick-off before the charter has been signed-off and many people will not attend (“this project does not exist, so why should I give my time to it…”). I suppose that whenever you hold it some people will be disappointed.
The best you can do is to explain your dilemma, and give people time to reconcile their ideals with your reality. At least you should get credit from them for identifying this potential problem.
And we might consider a kick-off meeting at several other times as well.
If the project is very long (more than 2 years in duration) each phase start should have a kick-off meeting. It is highly probable that the personnel will change; certainly the objectives and approach will change, so a kick-off meeting may be extremely effective at re-energising the team.
Maybe the project is put on hold, reassessed and restarted with new parameters such as scope. Well, a kick-off might be a good idea, to restart the motivation of the team members.
There is a real practical problem 2 or 3 months past the kick-off, when just 1 person joins the team. I will deal with the key skill of project team induction in a later post.
Remember the over-riding objective is to create the impression that you are capable of doing a good job and worthy of being followed. Don’t start out by creating a poor impression.
© Mike Watson 2012

Games People Play – White Knight

Number Two in a series of posts about games people play at work (and I don’t mean SuperMario….)
A game that insecure leaders play is that of White Knight. It works like this:
Your boss (the game player) delegates a piece of work to you, and does a poor job in this delegation transaction. He/she doesn’t give you all the information you need.
You start the task, and run into trouble (and the boss lets the trouble build up, for a time). Then you hear the trumpets blowing, and sweeping over the hill on his/her white horse is the White Knight, come to kill the dragon and fix your problems.
What a hero!
The White Knight uses subtle speech patterns to reinforce the superiority, such as ‘we made a real mess, but I managed to sort it out’.
In fact the White Knight is the villain, in that he/she set this up for you to fail (unconsciously, maybe, but just as guilty).
What your boss is doing is proving that ‘no matter how clever you think you are I can still do this….’
This game is played from the life position of an insecure leader trying to reinforce their authority in the face of competent and knowledgeable subordinates.
Like all of these games there is a winner and a loser.
It is difficult to counter, without looking like a cry-baby yourself. All you can do is console yourself that it means that the boss secretly believes you to be competent and knowledgeable – a threat to the boss.
It is a very destructive game. Just make sure that you play it on your team members.
© Mike Watson 2012

This is what you signed for – this is what you get

Many project managers think that they must deliver exactly what was signed for, in the original approved project charter.
Well, maybe in utopia…
The Scope in the original charter represents the best guess at the time the charter was signed off. It will change during the project, and in some business environments the degree of change can be considerable.
In a dynamic business environment, with a project team (and I include the users/customers in this) full of creative ideas, the scope will be under threat from Day 1. The sooner the PM realises this, and creates a simple change management process the better.
It is futile for the PM to stick to the ‘this is what you signed for’ mantra. The instinct might be ‘just give me a clear run at this and I will deliver what you ask for’, but the reality is quite different.
As long as we have a change control process then we can still deliver what the customer wants, but what they want at the end, not at the beginning.

 

© Mike Watson 2012