Sometimes The Rules Must Be Different

There is a big debate in GB media this week: should the Olympics and Paralympics be treated the same, combined or be carbon copies.  Aside from the practicalities (4 hour opening ceremonies and time tabling venues) Peter White (bbc.co.uk) reminded the media that there are differences and what suits a person in a wheelchair will not be a level playing field for those on two legs.  The country is learning new sports (e.g. boccia). Closer integration of the games might be possible but we must acknowledge the key aspect: these games are different with different rules. It would be unfair on all competitors to try to make them the same.

Some companies and project managers make similar mistakes seeing a portfolio of projects as homogenous and trying to endorse the same methods and processes. A fundamental definition of a project is that it is a unique undertaking. In organisations, the types of project they undertake may be grouped by type and complexity to help assign effective project management teams. However, many don’t do that, they group by location or year: accidental dragooning into manageable groups.

The underlying problem with accidental grouping is the assumption that a consistent management can be applied to the projects in that group. That is where the project that isn’t quite the same can be the performance management equivalent of a land-mine: hidden, explosive and unexpectedly damaging. These land-mine projects are damaging because they go wrong, add cost, demotivate the team and upset stakeholders. Sometimes the costs of these projects can stop the business performing in other areas. If the dispute goes to law it can have a catastrophic impact on the organisation.

Therefore, portfolio and programme managers need to find a way of identifying those projects that are different: different type of delivery, different type of client, more complex, bigger or smaller teams, longer or shorter timescales, new or innovative. They need to tailor their controls and processes to manage these.  This is adaptation for a situation not a licence to lose the overall controls applied.

I recognise that a number of Paralympic competitors first “qualified” for the trials that got them into their nation teams because of land-mines.  While “the project that brought down the business” isn’t really on the same scale, the metaphor works. Their life has been set on a new unplanned direction that is incomparably different from their original hopes and dreams. Their success as elite athletes may be a huge achievement and entirely worth celebrating but it is not the same: the rules are different.

Advertisements

Defininition, planning, avoiding rework and getting 40% savings in projects

On my travels I spotted a hotel advertising “lounge food”. That obviously means something to them. For me, it is something to label “jargon” and wonder what they mean. Do they mean nibbles to eat relaxing on a sofa? Or would it be dainty sandwiches, cup cakes and cream teas? Are they recreating historic banquets lounging in Romanesque opulence? Is this a reflection of the modern habit of eating in front of the TV rather than at a dining table?

As project managers our use of jargon can cause issues we could avoid: “stakeholder management” is a defined process which doesn’t mean the same to some. The need for precision in language is more important in defining the measures by which you know something is complete – project or product.

What does commissioned, usable or handover mean? How do you define acceptable performance or customer satisfaction? By carefully defining the detailed qualities and aspects of what you are delivering, and how you will measure that and when. This is work that often gets forgotten in the “just get on with it” cultures of some organisations.

It is worth remembering that the Olympic development projects used a 2:4:1 approach. Two years planning and defining, four years of delivery and a year of testing. Late delivery or failure would have been catastrophic for the organisations involved, so planning was seen as vital. I know from the discussions with some of the project managers that the planning and defining was not all done first but very little was started without being fully defined (including handover and legacy). There was also very little waste or rework.

By comparison, I have worked with a number of organisations that use a ratio of 1:6:3 (and they are not the worst). Their lack of planning means they do at least 50% rework, have to spend considerably more on testing to make sure the errors don’t get out and retesting after rework. Defining what you are doing, how you test it is complete and the measures you’ll use are worth the investment; about a 40% saving on the overall cost of the project.

Running On Ice

Summer isn’t warm enough for lots of ice but the metaphor struck me as so true in a project rescue I was discussing with an old client. Their new project manager joined to turnaround a project but seems to be making little progress.

With a little coaching, the client admitted that the project manager was being pushed to deliver fast but had no control over the things that were the causes of his predecessor’s struggles: poor portfolio management and resource churn.

When the team is constantly being churned, leaving, reassigned and re-forming, momentum is lost. Inductions and hand-overs take time that should be spent on the project. Rework become inevitable because the learning curves are being trodden every day. The lack of stability in a team means communications channels are restarted (or fail to include the right people) nearly every day. That is wasteful.

The portfolio management was broken. There was so much pressure to get projects out of pipeline and to “started” states that there were more projects in progress than the organisation had capacity to  deal with.  That meant the rare, highly skilled resources had more churn than anyone else. They were getting worn down.

Time for my client to face reality. They had to stop running on ice. We laughed at the metaphor but my client’s presentation may have a cartoon on the page were he delivers the  tough message to the senior team: be serious guys, either resource the teams for the projects we are doing or do less projects at once. In agile terms: minimise work in progress.

Lessons Learned are worth the effort!

The Canadian charity Engineers without Boarders is learning the way in looking at their projects openly, admitting what went wrong and sharing the lessons they learn through that process. That is a level of maturity many organizations don’t have – even if they have a process that says they do retrospectives or lessons learned. They say they have made more impact and reached more lasting goals because of this.  And they encourage others to do the same on http://www.admittingfailure.com

Read more of this post

scheduling decisions change atmosphere

What do Agile and the Olympics have in common?

The London 2012 Olympics have a few days left before the break to prepare the next phase (Paralympics). The home side have achieved golds (much to the relief of team officials who were beginning to worry if the pessimism of the media was correct). In fact, Team GB have had a very successful game. People have been inspired to take up sports either as fans or to stay fit – we’ll soon know if that commitment lasts

I have a new role and I’ve done my first two week travelling across London using public transport. That’s usually nightmare: rush hour is often “crush hour”. But it hasn’t been. why?

The London 2012 organisation has tried to schedule events so spectator journeys have been spread across the capital city at different start times. To keep the transport network flowing. They have invested in those areas that showed signs of  potential failure before they were needed.

The school holidays have helped and because of the dire warnings, some families have escaped the city. That removes the time constraints on the morning travel peak; “I drop the kids and dash to work” doesn’t apply.

Some employers have encourage working from home or changing working hours (one friend starts at 7 and is done by 3:30) and that means people have more flexibility over start and end times to allow them to get to evening events.

Others have taken holidays to escape the big show because they are not sport fans. They are missing the cultural events and the atmosphere. As one visitor from a more northern city commented, “this isn’t like London – it’s so friendly!” part of that is because there are more people to give directions and welcome visitors, letting the staff get on with other important tasks uninterrupted. there is also some extra capacity in the system (special buses)

The net effect is that demand is reduced and spread across more time and people are being patient with each other.   It is all about scheduling, resourcing and capacity buffers. Agile approaches aim to minimise work in progress and flatten out the resource peaks. That works in a similar way by removing the usual assumptions about scheduling constraints.

Will London change forever because of this? Unfortunately, no. The children will be back at school for fixed hours. Parents will all be heading to work at he same time pushing capacity to the max. The festival spirit and extra people running the system will disappear. Some employers will revoke flexible working.

But imagine if we could remove those constraints and keep this calm, friendly, capable transport system. Now imagine what a little rescheduling might do to remove the stress from your project.

Vision, Mission, Objectives, Requirements, Measurement

“I have a vision, your mission is to get us there”. Project managers hear that sort of comment at least once in their career.

So what is a Mission? Who has Visions? How to these relate to the things we need to work with: objectives and requirements. Vision and mission are related and they must be coherent in content. However, but they are different in character. In system terms, one is a description of a state, the other is the motivated activities to reach that state.

Vision is a picture of the future state.

Mission is the movement towards that state.

With so many management gurus talking about different ways of defining the two, why am I sure that it is that way round?  Well, you see a vision and there is a quote, “your mission, if you choose to accept it, is to …”? That’s about activity because only a verb can follow that: so mission is about activity.

In cultures where it is the leader’s job to have the vision,  share it and discuss it with the team. The team’s questions and knowledge can refine the vision. Building a vision together from step 1 may work more effectively for other cultures and organisations.

The understanding of the vision as a team is vital to the success of the mission – if you can’t understand what it looks like when complete, you can’t define the mission and know when you have achieved it. Having a compelling vision can motivate the team because they are engaged in it and have helped refine it. The vision can give indicators for completeness because it is the future state you are working towards. If you make those things measurable, you can test for completion.

The mission can be expressed as activities each with an objective. Ideally one objective will bring the mission into sharper focus and remove distractions from the team. Sometimes that isn’t possible but certainly objectives expressed with clarity are easier to deliver.

Time to think about those measures again. How does the objective contribute to meeting that measure? If it doesn’t have you got the right objective and how can you justify doing something that takes you further away from your vision in one or more of the aspects you found important enough to measure? Or did you not define measures that truly reflect what the vision needs you to achieve?

So how do you arrive at requirements? The vision, mission and objectives only make sense if they satisfy stakeholders. Requirements are retailed technical descriptions of those needs and how meeting them can be measured. The vision, mission and objectives will only be valid if that context means the requirements can be met.

With the requirements, you can validate a vision and mission: given our stakeholders’ requirements are we looking at an appropriate vision of the future? Do the requirements mean we are looking in the wrong direction? Similarly, to validate the set of requirements, it would be sensible to ask if there are parts of the vision, mission and objectives for which the requirements are insufficient or plain wrong.

Legacy already

It used to be that I would expect the PCs being installed on desks would be one model behind the market – something would have been adjusted or replaced in the new model but it would not be so far ahead of our newly tested installation. In some suppliers the speed of innovation has increased and the availability of supply and services expands almost daily.

There is nothing more frustrating to me than towards the end of a project attending the launch of a product or service that you wished was available at project start. That is what happened to me today. We had the vision of focusing of the customer’s contact preference, being responsive, integrating backed systems with customer side service.

The organisation is close to the installation of the final part of the last phase of the 80% solution and I have just met a company that is launching proven technology that does exactly the unified Communications and CRM we wanted but wasn’t available in the UK. They have been in the USA and Europe for 4 years, today they launch in uk. The best solution available is legacy already – before the project managers have signed off the last work. While the return on investment will be realised, it won’t be the shiny new system we wanted on day one.

That is the frustration in business solutions – for most organisations, the solution is out there but finding it is harder.

Project in Trouble: Don’t Panic!

Something about the current debates about English secondary education (age 11 to 16 years)  has reminded me of a project that didn’t go well.

The debate about introducing a new qualification before completing a review of the system (http://www.parliament.uk/business/committees/committees-a-z/commons-select/education-committee/news/ebac-report-substantive/) is beginning to look like someone with power was making a big decision based on opinion and a perceived need to act quickly and not a more objective view – and after a few weeks the situation looks starkly different.

Sometimes, a manager must make a fast decision based on the information available because there is no time left to contemplate. However, often waiting for your team to give more information or think of alternative can mean a better decision. Action is vital when a project hits a problem but panic reactions and instinctive firefighting can lead to more trouble.  Unfortunately, that a problem has been found can build a desire to take decisive action fast.

I was in the meeting when Joe (the project manager) realised that his team had discovered something that was going to put him wildly over schedule and put a huge hole in his project budget. We talked about how he could calmly take this forward and rescue best value from the project for the stakeholders. He had some ideas but realised he needed more information from the team and had to test out some potential solutions.

He had a real sense of urgency about him when I left that meeting: he was telling his team that they must get all the work they had in hand to a sensible point to leave for a few days. The project team would need time to work on what to do about this issue. They agreed a good place to start was a workshop about the facts of the problem before they left that evening.

I knew Joe had a regular lunch meeting booked with the Mark (the senior manager responsible for the project) the next day. That seemed like a good opportunity to talk about the issue, bring some early information and ideas, and ask for support and guidance from Mark. It all sounded like a plan to get to a new plan.

I went on a business trip for a few days. When I got back, I could only wonder at what had happened.

The project team were running in various directions with panic written across their faces, Joe looked downtrodden and Mark appeared to be the new project manager issuing instructions to everyone but there was no sign of a plan.  Everyone was in firefighting mode but without the calm disciplined approach I know trained firefighters have. That didn’t seem to be an improvement.

I had a quiet coffee with the very stressed Rob (PMO consultant assigned to the project) and got the story. Joe had done all the things he and I had discussed. The team had defined the problem sensibly and had some ideas that might work but these were not complete before lunch with Mark.  Once Mark had heard the details of the problem he quickly knew how important it was.

However, just as Joe was about to discuss his ideas and plan, Mark got a phone call from his boss who demanded why he hadn’t taken change of the problem as 24 hours had already passed.  How the boss knew about the problem we never found out but Mark’s expression changed as he was berated and he was heard to say “I am already on it … I’m meeting with Joe now … I am confident we can find a way to satisfy this customer …of course I’ll take charge myself”. Now Joe and Mark are both trapped in a senior manager’s “Just Get On With It” pronouncement from afar.

Mark saw Rob and I return from our meeting and called us into his office. That at least gave the project team some respite. Sometimes, I just say the wrong things: “I see the solution to the issue isn’t progressing well – what does your plan look like?” After Mark described his frustrations for about 10 minutes, Rob started to relax and there was silence. What now? The only thing I could say was, “why don’t we call Joe in and see how far we’ve really progressed and what ideas his team has now?”

By the end of the day, we concluded that

  •  all the activity had made some progress but not as much as we could have done,
  • we had learnt some lessons and gained some valuable insights into the solution,
  • we could see a logical plan to solve the issue by the end of the next day,
  •  Mark was paying for the team dinner that night as they agreed to work late to make up the time he’d lost.

That dinner was considerably more elegant than the pizza the project budget might normally have yielded. The team was as good as their word and produced the solution the next day. They also had some other ideas which improved the project as a whole, made money for the organisation and delighted the customer.

Will the education debate end so happily? I do hope so. When I think of that team, they were all very intelligent and able – partly thanks to their education.

Twitter for project managers (4 of 4)

The first 3 parts were about Twitter, it’s conventions and how to find and share information. This final post in the series, Part 4, suggests how to use Twitter for a project

Please add your ideas and comments if you are a #pmot (project manager on Twitter). What works for you?
Read more of this post

Twitter for project managers (3 of 4)

Parts 1 and 2 were about Twitter and it’s conventions, Part 3 suggests how to find useful information and collaborate on Twitter
Read more of this post