Tag: project management

Too many projects, too much change

I may have mentioned that I’m taking a 5-week Coursera course, Bridging the Gap between Strategy Design and Delivery, developed by the Brightline Initiative. I’m going to write more about it when I’ve completed it but meanwhile one of the module topics I studied this week is particularly relevant to some work I am currently doing.

It’s about projects and change.  Perry Keenan of BCG talks about the ‘increasingly artificial split– between running the business and changing the business’.  (You can watch the four minute video here)

He talks about the issues with too many initiatives, saying ‘Arguably, it is in fact easier to add an initiative than it is to stop one because there’s a lot of connection – political, emotional, historic– a set of factors which means it’s not easy to stop initiatives. It’s often not easy even to slow them down.’  He goes on to advise, ‘If you’re going to add in new initiatives, then be very thoughtful about what it means for the initiatives that you already have in play and the demands that you’re placing on your people. Once again, we all too often, in theory, assume that there is an infinite pool of highly capable people available to deliver the strategic initiatives. It’s a finite resource. And therefore, it has to be managed in a very definitive way.’

This chimes with an article I read in the Harvard Business Review, Too Many Projects. It opens saying ‘it’s surprisingly hard for organizations to kill existing initiatives, even when they don’t align with new strategies. Instead, leaders keep layering on initiatives, which can lead to severe overload at levels below the executive team.’  The article cites six further reasons for why this change overload occurs

  1. Impact blindness:  executive teams can be oblivious to the number and cumulative impact of the initiatives they have in progress.
  2. Multiplier effects: leaders have a line of sight into their own groups’ initiatives but a limited view of other groups’ activities. Because functions and units often set their priorities and launch initiatives in isolation, they may not understand the impact on neighbouring functions and units
  3. Political logrolling: Executives tend to be strongly invested in some “signature” projects and may garner resources for them through implicit agreements to support their peers with their projects
  4. Unfunded mandates. Leaders want a project to happen but don’t have the resources to put to it. Instead just adding it to the ‘business as usual work’.
  5. Band-Aid initiatives; this is a proliferation of initiatives designed to solve a problem, but without address the root causes of the problem in the first place
  6. Cost myopia; leaders fail to estimate, or underestimate the human cost of multiple initiatives on performance, motivation, morale, stress and so on.

In case you don’t know whether your organisation has too many change projects/initiatives, there is a 17 item yes/no questionnaire – one of the questions, for example, is ‘Does the organization lack processes for quantifying impact and prioritizing initiatives? Yes/No.’   The instructions read, ‘The first step in dealing with initiative overload is to honestly assess and acknowledge the [overload] problem. Ask yourself the questions below to gauge whether your organization is at risk. Then total up the yeses—those are red flags. If you have more than four, you may need to better manage the number or timing of initiatives.’

Since most of us completing the survey scored at least 10+ it served to confirm what we already knew (or at least, felt), that we are at risk and need to better manage the number and timing of initiatives.

The difficulties lie in converting a strong feeling that we are at risk into evidence proving that we are, and then doing something about it.  Both Keenan, and the HBR authors highlight the problem and the impact of the problem, but don’t specify or hint at any practical guidance on mitigating the risks and/or stopping the overload.

One of the things we are feeling is a risk is discussed in an article The Long-Term Damage from Juggling Too Many Projects – it notes that ‘Scrambling to shift scant resources in order to meet deadlines can have a chaotic ripple effect.’  That ripple effect is not just on the timeline and delivery schedule of competing projects and ‘business as usual’ but also on the people involved.

That’s the area I’m interested in.  I’m wondering if there’s a way we can look ahead to forecast the likely project load on people and take steps to even out the flow, slowing it down, speeding it up, or moving resources in a planned way and not a reactive way.  It’s necessary as in our case many people are doing project work alongside their ‘day job’.

I want to create a ‘heat-map’ that forecasts what one writer describes as ‘change collision’:  ‘Change collisions occur when there are multiple changes hitting individuals or a team of people over a common timeframe. Often, change collisions are a small number of high impact changes. In some cases, however, these collisions may be a high volume of low impact changes that didn’t garner attention until understood in the aggregate. Keep in mind that other “rhythm of the business” activities, driven by the organization’s calendar of events, should be taken into account as well when considering the volume of change activity.’

Talking with colleagues on the issues of project overload led to a number of interesting, still open, questions:

  • What’s the tipping point between projects that remain manageable and the point of overload?  How could we recognise it?
  • Is project overload to do with leadership and communication as much as the demands of the projects themselves?
  • How do we reconcile change due to project delivery and implementation and change in ‘business as usual’?  Does one feel more overloading than the other?  Or is it the combination that causes overload?  (In our case many people are doing project work alongside their ‘day job’.)
  • Is something we call ‘too much change’ related to projects, the general operating context changing, other factors changing and is the source of the ‘too much change’ feeling identifiable (and does the source matter?)

We are interested in the human indicators of overload and began to develop a list of metrics that we could track and link back to the project plans.

People suggested a range of other measures that fell into four impact categories: resilience, successful delivery outcomes, work/culture and resource.  For example, in the successful delivery category,  if we the rise of reports in bullying and harassment coincides with some project delivery target(s) is there any connection to investigate?  Or on in the resource category,  if we saw a sudden spike in people working weekends and logging overtime is there too little resource on the project?

Right now, we are playing around with the ideas of how to measure this cumulative impact of projects and associated change with a view to gathering data to test some of our ideas and convert them into an evidence based heatmap.

How do you measure the cumulative impact of change on your workforce members, and how to you use it to smooth the change flow?  Let me know.

Image:  Overloaded

Do-ability

Were you as amazed and thrilled by Elon Musk and team’s feat in launching Falcon Heavy + roadster with Starman, on February 6 as I was?   My delight at a massive bet that paid off, couldn’t match Musk’s own.  “Holy flying f—,” Musk says in the video, seconds after the Falcon Heavy pushed off the launch pad. “That thing took off.”   Watching the rocket go skyward, Musk exclaimed, “That is unreal.”

At a press conference later that day he told reporters, “Crazy things can come true. I didn’t really think this would work — when I see the rocket lift up, I see a thousand things that could not work, and it’s amazing when they do.”

I can’t claim that an organization design/transformation project could generate anything like the same reaction as the crowds at the launch site at NASA’s Kennedy Space Center in Cape Canaveral, Florida.  If only they did.  We don’t celebrate success of a project in much of a way.  Maybe we should.  As Elon Musk said “I’ve seen rockets blow up so many different ways, so it’s a big relief for when it actually works.”

What I loved about the Falcon Heavy is the sense of the absurd harboured within immense endeavour.  Musk’s roadster car with Starman figure is the payload, “It’s just literally a normal car in space — I kind of like the absurdity of that,” Musk said. “It’s kind of silly and fun, but I think that silly, fun things are important … I think the imagery of it is something that’s going to get people excited around the world, and it’s still tripping me out.’

I don’t see much silliness and fun in leaders of organisation transformation. And it’s a pity we don’t encourage it, because, as Musk says – that’s what’s going to get people excited. (Or not)

In the same week as the Falcon Heavy take-off, I was in a programme planning meeting (on organisation transformation), where the question of ‘do-ability’ of what we’d designed and planned came up.  It’s not in the same league as off to orbit Mars but it’s important in our micro universe.

Asking if something’s do-able is a good question.  What are the conditions necessary for making an aspiration or a plan do-able?  Are there common factors of ‘do-ability’ that we should look out for?  Learning from Musk’s and the Starman venture we can identify:

  1. A leader capable of putting together a truly expert team of people dedicated to achieving the common mission even if it looks like a big risk at the outset. Musk points out that ‘there’s a tremendous bias against taking risks. Everyone is trying to optimize their ass-covering.’
  2. Having enough cash and other resources available to fund the project from initiation to outcome (and onwards)
  3. Doing a lot of planning and accepting you can’t plan for everything. “We’ve done all the (computer) modeling we could think of,” he said. “We’ve asked … third parties to double check the calculations, make sure we haven’t made any mistakes. So, we’re not aware of any issues, nobody has been able to point out any fundamental issues. In theory it should work. But where theory and reality collide, reality wins.”
  4. Showing a reasonable sense that things might not work out but that whatever the outcome there are great learning opportunities. “It would be a really huge downer if it blows up. But hopefully, if something goes wrong, it goes wrong far into the mission so we at least learn as much as possible along the way,” said Musk at Kennedy Space Center on the eve of the flight
  5. Being willing to say clearly that this is not going to be right first time. Musk pointed out, “This is a test mission. We don’t want to set expectations of perfection by any means.’ (He put the odds of a successful flight at somewhere between 50 percent and 70 percent which is the often quoted, but maybe not accurate,  success rate for change and transformation projects)
  6. Recognising that modeling and scenario planning are not failsafe. For Falcon Heavy, ‘It is also difficult to model the vibration and acoustic environment at the base of the rocket where the 27 Merlin engines will be firing. The engines were test fired at the pad on Jan. 24 and SpaceX said later there were no problems. But, Musk warned Monday, “there’s so much that can go wrong here.”’
  7. Giving an implementation timeline but being prepared to move it out. Musk, ‘the SpaceX CEO is known for his — let’s call them “aspirational” — timelines.’
  8. Having done the planning, then being willing to take the risk of moving ahead knowing things may not work out.  As Musk says ‘you’ve got to take big chances in order for the potential for a big positive outcome’

Now I’m looking at that list and thinking that isn’t totally convincing as a complete list of do-ability criteria.  It’s a good start, but insufficient because Musk is not your average programme director or middle manager.

Most project do-ability conditions are also about more prosaic things like maintaining business as usual while introducing the new ways, working with sudden budget cuts or loss of key staff,  overcoming the difficulties inherent in patched together legacy IT systems,  having the ability to change organisational policies and rules, overcoming the long shadow previous transformations cast, working through the organisational politics, and being reasonably confident that organisational data is valid, current, reliable, and easily accessible (quite often not the case).  I’ll add those to my list.

What are your project do-ability criteria?  How do you create the conditions to make a project do-able?  Let me know.

Image:  The roadster in space

If you want to know where the roadster + starman is now, look here where there is an up to date tracker.