Top 10 things that people do wrong when trying to manage that tricky temporary endeavour that is designed to bring about a positive Change…

They put an inexperienced ‘non’ project manager in charge – projects are just different and you need to have the experience to lead them

  1. They don’t treat it as a new activity that deserves focus and attention, but rather they behave as if it is just an addition to their current workload – the danger is that the project is not thought through from start to finish and given the appropriate priority of their time
  2. They don’t give the time needed to the manager of the project to do the job properly – which leads to a bad job, or excessive extra hours and possibly a bad job
  3. They don’t support the project manager by partnering them with a good executive project sponsor, but instead leave the project manager to just get on with it – often ending in frustration and lack of resources from the organisation above
  4. They never consider risk once the project begins – which leads to surprises, sometimes nasty ones that can derail the whole project
  5. They assume that when people are allocated to a project they will do everything asked of them as a priority, when the reality is they have a day job as well, which will be the real priority – it never ends well and typically doesn’t get the work done on time
  6. They don’t communicate effectively – this requires the right information delivered in the right way at the right time to the right person – and reporting is not communicating
  7. They say ‘yes’ way too often, just to be nice – change is both the greatest opportunity to a project manager but also the greatest risk – people wanting more and more from the project will ensure it never ends
  8. They don’t care about the outcome of the project, it is just another job to do – without care there is never consideration or effort

And number 10… They fail to think of that all-important ‘work/life balance’ – projects are about people and a good project manager should always take this in to consideration and should definitely be ‘lazy’.

This means that we should all adopt a more focused approach to managing projects and exercise our efforts where it really matters, rather than rushing around like busy, busy bees involving ourselves in unimportant, non-critical activities that others can better address, or which do not need addressing at all in some cases.

Peter Taylor is known as The Lazy Project Manager and is a project management office (PMO) expert.

He is currently leading a global team of more than 200 project managers acting as custodians for more than 5,000 projects around the world from Kronos Inc., a billion-dollar software organisation delivering workforce management solutions.

Peter is also the author of eighteen books, including the number 1 bestselling project management book, The Lazy Project Manager. In the last four years he has delivered more than 200 lectures around the world on his mission to show people how to work smarter, not harder in their quest for career success. and

Read more:

Someone stole my operating rhythm

I think that I have rhythm, I can play the guitar and I dance around the kitchen a lot. In my youth I masqueraded in a band and went to a lot of dance music events. I used to dance a lot and I recall at least one other person saying that I had rhythm.

I looked up a dictionary definition of rhythm and found the following:

‘A strong regular repeated pattern of movement or sound.’

‘A particular type of pattern formed by rhythm.’

What I did not find in the dictionary was:

‘A management approach to maintaining relationships and performance’

It seems though that over the past ten years management has been systematically (if not rhythmically) stealing my rhythm and molding it into their management speak, operating rhythm.

‘Who are these villains?’ I hear you cry. Well I asked Google and returned about 11,000 results. That didn’t help so I tried to find who coined the phrase but no joy there either. What I did find though was interesting, it seems that before management operating rhythm there was manufacturing operating rhythm.

MOR has its basis in lean and the benefits of sharing. So MOR is defined as the sharing of information collaboration and cyclical or systematic communication. I think that we can all agree on the importance of these aims, collaboration, sharing and communication and we would agree that doing these things at a regular interval would be potentially transformational for a lot of organizations.

It still doesn’t explain the fact that management has stolen my rhythm but I’m starting to see the what is meant by an operating rhythm. Before I endorse it though what about the benefits? How about:

  1. Innovation and creativity
  2. Trust and belief leading to controlled risk taking
  3. Support linked to people, capability and product development
  4. Faster time to market through better, more informed decision-making

Really, all of those things? Well consider the barriers to any of the four benefits listed above:

  1. Incompetence
  2. Ignorance
  3. Lack of trust
  4. Poor insight

Do you remember the Kodak funsaver? It was launched in 1989 way before lean and agile became trendy and way before operating rhythm was pinched from me. I would say that the funsaver, the first disposable camera was a game changer. It proved to be a dramatic strategic vehicle for Kodak and it changed the way in which consumers used cameras. Canon, Konica and Nikon all filled into a market that was to camera’s what the iphone was to mobile phones.

What is interesting about the development of the Kodak Camera can be found shuffled into a French business magazine, published last year. It throws light on the methods that were used to develop this radical technology in a short (6 months) period of time. It started with the creation of a laboratory, physical as well as metaphorical. Bright representatives from different areas of Kodak were brought together with the brief to ‘create something new’. The article author refers to this as a mini organization within the larger organization, we might refer to it as an autonomous project team. There was a ceo a developer a scientist a customer representative and marketing representative and a technical engineer. In scenes that agile practitioners would recognize this team would meet on a Monday and discuss what they would do that week. Following on from that meeting they would work closely together over the course of a week, developing the concept until Friday when they would review and make recommendations for the next week. It seems both far fetched and idyllic but the outcome was and is spectacular.

If I refer back to the four benefits I listed earlier, one could summarise that innovation, creativity, trust, belief, support , decision making and speed to market were all evident in this autonomous project team.

So I’m still not happy about the word but an operating rhythm seems to be useful, beneficial, radical maybe even game changing … it’s also really common sense. My friend Alan at RBS talks about it a lot and he’s seen it implemented lots of times, sadly he’s also seen it fail lots of times. So here are my five ingredients to implement and to maintain a good operating rhythm.

  1. Identify the things (competences, values) that need to be done on a regular basis to develop the kind of behaviors and performance that are required for business success (communication, sharing, collaboration, creativity, people development)
  2. Break down number one into repeatable practical activities that can beset up easily, carried out quickly and maintained imply on a regular basis (morning meeting, weekly catch-up, joke of the day, idea of the week a coffee race, the more fun the more engaging and lasting)
  3. Get the team involved. Find ways to enfranchise them into the outcomes, benefits and activities so that they themselves own it, drive it and want it. (Seek idea’s, influence, sell, delegate, engage)
  4. Agree a plan (our plan) to start and implement the practical activities that make up your operating rhythm.
  5. Agree and constantly review the practice, the application, the benefit and the engagement of the rhythm.

With the absence of some sets of trance music, one of the exciting things about dance music is that the beat stays the same but the accompanying sounds and melody change. It becomes hypnotic but inspiring. If you like music you’ll find that occasionally (often for me) it’s important to change the CD, the vinyl or the play list. The same thing applies to a management operating rhythm. Please, keep the beat but make sure the tune changes and remains inspiring.

What people want and need – Essentials

Welcome to this second blog in the series, expectations management.

In the last article I Suggested three things that you should know about expectations management and you may recall that I mentioned Kano and his expectation model.

In this article, I would like to explore a bit deeper on the subject of what people want versus what they actually need and how gaining this insight can feed into satisfied enfranchised stakeholders.

Picture the scene: A dozen people ranged around an oval boardroom table, tense and concentrated expressions, documents, post-it notes and coffee cups disorderly evident on the table top. There is a tense atmosphere and at the heart of this discussion is a business stakeholder who is insisting that the software upgrade be completed on time and within budget by the 31st December.

The situation report states that due to the late start of the project and various changes (some of which were not approved through governance), with three months to go the upgrade cannot be delivered to the original configuration of time, scope and budget.

On the table are three options:
1. Use external resources to crash the effort, reduce the duration and meet the deadline. The cost will be £250,000.00
2. Upgrade on a needs basis with key users getting it first followed by a staged upgrade that would last six weeks beyond the original go live date but would provide functionality to 10{e8a48bf1014efa1f514ba2ea7b318659948c550611071653509ba02309d505df} by the year end.
3. Extend the go live date into January and have a full implementation by mid January.

The tense nature of the discussions centre on the business stakeholder being unwilling to budge. In their repeated opinion, additional budget is not available, a phased approach would add more complexity and while providing a small early win, would delay the overall completion date and that extending time in any case is not an option.

One of the participants takes a deep breath and asks, ‘Can we remind ourselves why 31st December is the absolute deadline?’
‘Because,’ says one of the advisors (from the software company) not without sarcasm, ‘the support expires on the 31st December and we would have 1,500 users with unsupported business critical software.’
The questioner presses on despite and asks, ‘How often have we used support in say the past 12 months?’ Of course this creates a pause and the participants look at each other, finally eyes resting on the figure of the support manager who is busily consulting a tablet.
‘150 times.’ He states but, as the table turns towards the original questioner he adds, ‘145 non critical admin support queries and 5 level two change requests.’

Can you imagine what happens next? Fortunately at this point the business stakeholder is astute enough to ask the right questions and establish that the statistical risk to delaying go live by two weeks is around 6 non critical admin support queries and so the project is successfully implemented in the middle of January with no additional cost or scope compromise.

This is a scenario that many of my readers can relate to. Imposed, preferential requirements that do not bear up to scrutiny but the process of bringing scrutiny to bear is often late and in time of crisis. I would like to propose a practice that brings the scrutiny up front and enfranchises all stakeholders in doing what it tales to deliver what is needed, not what is wanted.

It’s not complicated but is is difficult and it is getting stakeholders to prioritise their requirements and then to take an active part in the debate and decision making that is required to deliver an effective and welcomed solutions. My colleague Vicky, a super BA consultant talks a lot about ownership and how ownership cannot be bestowed it can only be volunteered. I agree entirely and would like to propose the following practices to get stakeholders to own their requirements and the necessary involvement to prioritise and get them bought in.

1. Find a way to gain the interest of each stakeholder in providing their requirements (what’s in it for me?)
2. Using post-it notes, get each stakeholder to write down their requirements and post them on a roll of brown paper, flip chart paper or other.
3. Ask them to describe each one, or help them to describe each one and to prioritise which ones they would pay for as being the most critical, which ones they would expect as standard and which ones they could do without.

Step one is critical and sometimes this involves other stakeholders as more appropriate that you to create this initial interest. It might be the fear of missing out, it could be group think, it could be personal incentive. Get them in a room ready to contribute.

Step two is about buy-in and commitment. It’s human nature that people will consistently support an initiative that they have had a hand in creating. The simple act of writing on a post-it note and placing it on a board demonstrates commitment that can be built upon later. Fact.

Step three is interesting and true. The paid for requirements are important but rarely essential, the expected ones are generally essential and if you get any ones that they could do without well they are a bonus.

Seen together and in practice this process provokes healthy debate and discussion that should ultimately lead to stakeholders who own requirements and the process required to effectively manage and prioritise scope throughout design and delivery.

What stakeholders want is a fit for purpose solution and no surprises. Following some simple steps can help them to achieve that.

For more information on this and other stakeholder matters, see It’s the People. Practical Lessons in Project Leadership and Stakeholder Management