The Money Files

At PMI’s Synergy conference at the end of last year, Stephen Carver gave a well-received presentation which included some information about the different types of complexity, as perceived by the brains at Cranfield.

He talked about what success looks like on projects and said that the level of complexity faced is part of whether a project is deemed to be a success or not. The 3 types of complexity he identified are:

• Structural
• Emergent
• Socio-political.

Let’s look at each of those in turn.

Structural complexity

This is the ‘easiest’ level of complexity and it involves the scale of the work on the project. A project is structurally complex when it has many stakeholders, workstreams or other elements. There is a lot for the project manager to manage and control, with many variables.

Emergent complexity

This is where the project is changing around you, for example increases to the price of steel in a construction project or stakeholders who were not identified at the outset suddenly needing to be included. It encompasses projects where there are a number of unforeseen issues or where the situation is unknowable, for example where there is a great deal of novelty perhaps in the technical set up or the way the commercials are being managed.

Socio-political complexity

This is where the project suffers from hidden agendas and lots of politics. There is little transparency and at the worst end of the scale maybe even sabotage. There are conflicting priorities and resistance. Cultural IQ becomes really important for the project manager along with being able to adequately manage the people involved and creating a shared understanding of objectives and the project’s vision in order to align agendas effectively.

Stephen said that most training courses cover dealing with structural complexity but in a survey of 246 project managers who were asked which of these 3 areas they found most challenging, socio-political complexity came out on top.

Which is hardly a surprise.

“Projects,” he said, “are deeply emotional things.” Whether the Millennium Dome, for example, was seen as a success or failure is down to your point of view and the passage of time: rebadged as the O2, it’s now a very successful arena and venue. The Sydney Opera House, Concord and Terminal 5 at Heathrow were other examples he gave of projects where the definition of success was difficult to pin down and would mean different things to different people.

“If you don’t do anything, you won’t make any mistakes,” he added. “We do a lot so we are bound to make mistakes.” Unfortunately, on complex projects these mistakes tend to be in the socio-political arena and they can be very hard to undo. Not setting up proper workstream reporting, for example, might give you a structural problem at the start of your project but it’s easy enough to address that sort of complexity and put it right. Dealing with damaged egos or senior stakeholders who each think the project is going to address their own pet issue is a far harder situation to deal with.

He didn’t give any pointers as far as I can remember about being able to deal with socio-political complexity, although I imagine that a 45 minute presentation about project success was never going to have much time to touch on what project managers can do differently (better) in order to address these challenges.

What tips do you have for managing projects with this type of complexity? Is it just good stakeholder management or are there other things that you can do to deal with it successfully? Share your thoughts in the comments below.

At the PMI UK Chapter Synergy conference (you can see the stage in the photo) last month Hamish Taylor spoke about innovation and getting projects off the ground by looking outside your current industry for inspiration. He is ex-CEO of Eurostar and took over there at a time when the company was facing a loss of £206m. On the day he started they didn’t even have a product to offer as a fire had closed the tunnel and stopped the service.

However, he started off his talk on innovation by introducing his experiences from working at BA. He was instrumental in the project to deliver the world’s first flat bed – while now that doesn’t seem very innovative as all airlines off them, at the time it hadn’t been done before. He started off by approaching the normal company that made their airline seats but the manufacturer wasn’t able to think creatively and the finished designs didn’t really do what Taylor wanted. So he looked outside his industry for people who were used to designing luxury in small spaces.

He ended up approaching a yacht interior designer and they went on to design what eventually became the beds that were used in First Class.

Taylor used the same innovative approach when looking at how they could improve the customer experience at the airport. In 1993 they were struggling with check in queues and customer complaints were going up. So he looked at places where queuing wasn’t a problem, and could even be fun. He got executives from Disney Parks to come and observe the airport and point out what they were doing wrong.

This was at a time, he said, when each check in desk had an individual queue, and whichever queue you chose it was always the slowest. No one was doing a ‘zig zag queue’ where you join one queue and go to the next available desk. But that’s what was happening at Disney. Taylor’s team also picked up some other useful points from the Disney visit:

• Make the queue really narrow because then it moves faster, even if it makes the total queuing time the same. People will be moving forward so they feel as if the queue is going down and be more satisfied.
• If there’s a 25 minute wait from this point, tell them it will be 30 minutes so they feel s if they’ve beaten the system when they arrive earlier.

As a result of these simple changes, customer complaints about check in time went down – but the answers weren’t available in the airline industry at the time.

Understanding your customer for projects

“We need to change the way we understand customers,” Taylor said. “We’ve got to get better generally at soft insights, not data.” Insightful customer understanding, he explained, comes from understanding the customer’s world, and to illustrate this he gave an example from his time at the helm of Sainsbury’s Bank.

The project was to set up the bank in the supermarket. The traditional approach suggested a bank information point, with leaflets and a desk staffed by people in uniform. In short, a traditional bank, but just situated in the supermarket.

It didn’t work.

The ‘soft insight’ here was understanding the customers’ mood. When you go food shopping, most people want to get in and out of the supermarket as quickly as possible. They are in a bad mood. They don’t want to have a 20 minute discussion about credit cards while the ice cream melts in their trolley. So instead, the project team created simple products marketed at the right place in the store, for example, pet insurance by the pet food.

Making it customer focused

Taylor gave another BA example in his presentation, that of a project designed to increase the amount of people travelling business class. In their first advertisement, the focus is on the fact that business class has the widest seat in the world. It’s safe, secure, extra comfy and so on. But it’s not about the customer – it’s about the features of the seat.

Then Singapore Airlines launched a seat that was half an inch wider, and the ad campaign had to be scrapped.

Two years later, the ‘BA Club World’ project team had a different focus. It was about helping travellers arrive ready to work and making their journey as smooth as possible. The whole company was engaged with the vision: “How else could you help people arrive better prepared for business?” Taylor knew this approach was working when a member of staff from the lounge called him up and suggested that they serve a meal there as an alternative to having to dine on board. This way, business travellers could get more sleep on the flight and arrive better prepared for their working day.

“Project management is the catalyst for change,” Taylor said, and while he gave plenty of examples of projects, the key message was that unless you look for innovation, you won’t stay ahead of your competitors. As project leaders, we should be encouraging innovative approaches in our project teams and supporting projects that take a slightly different approach – you never know where that might lead in terms of innovation and success.

In his book, Project Management for Musicians Jonathan Feist talks about several ways to mitigate risk, and they aren’t the ‘avoid, mitigate, reduce, transfer’ approaches that you are used to. Those are good, but they are approaches, they aren’t actual measures that you can take to mitigate a risk. Here are the 7 ways that Feist suggests you can reduce the likelihood that something will become a project issue.

1. Good project management

Yep, following good project management principles is top of the list. Of course, having a lovely Gantt chart and an up-to-date risk register won’t guarantee project success but it does give you the best chance of putting in place plans to mitigate that risk.

Make sure your risk management processes are up to scratch and that you are able to easily follow through on mitigation actions. Good project management also helps manage against risks of going over budget or missing milestones, because you’ll naturally be doing the things to stop these becoming a massive problem.

2. Written agreements

While you always have to factor in how someone else will interpret your written communications, putting things in writing can limit misunderstandings. It also gives you a sense of formality when it comes to contracts and agreements. Getting it all down on paper increases the chance that nothing is being missed.

3. Checklists

I love checklists and I use them all the time. As Feist says, “Checklists help you remember important details: procedures, gear items, points for conversations, people who need certain information, and more. Checklists are among the most effective tools used to reduce risk.” I have recently written a peer review checklist for my team – one of the many ways you can use checklists on a project to look at potential areas of concern and do something about them.

4. Cross-footing

This means calculating data in several directions to confirm that it’s correct. You add rows as well as columns on your spreadsheet, or check the data in a dashboard as well as a tabular report. Find different ways to double-check your maths or working, even if this is as simple as having someone else check for you.

5. Empowering competent people

If something does go wrong, you want your project team to be able to act appropriately and make decisions quickly, not sit around wringing their hands until you come in to the office to sort it all out. If you have competent people on your project team (and I hope you do) instil a culture where they can make their own decisions. Set levels to their decision-making power as appropriate so that they aren’t deciding to spending another million dollars on the project without anyone else approving it, but give them the freedom they need to do the right thing.

Feist says that the higher the risk, the more you want to make sure that if you are delegating tasks they go to someone who is a safe pair of hands. This isn’t the time to be delegating work to a junior colleague as a ‘learning opportunity’!

6. Developing emergency plans

Having a Plan B is important, and a traditional risk management technique that you are probably familiar with. Sometimes just having a back up plan is enough to make sure that the risk doesn’t happen. However, in case you do need another approach to dealing with a problem, it is useful to have already thought through what you will need to do in the emergency. Get everyone involved so that they can swing into action if and when they are required.

7. Written instructions

Like checklists, these are a great help if you need to distribute detailed instructions or have tasks that need to be done over and over again. Written instructions can also help clarify expectations. For example, on an IT project with a testing element, written instructions for the testers will help get standardised results and ensure consistency across several testers.

Have you used any of these methods on your projects? Let us know in the comments.

In this book, Bonnie Biafore aims to share the basics of project management and how to achieve what you want to do in Microsoft Project 2013. That’s quite an ask for one book. Part 1 is a primer on project management and I was surprised that there was so much about this including project selection. It’s written as if it is aimed at a complete beginner – at least, the early bits are; the book gets technical pretty quickly – and there are nice boxes called     ‘reality check’ scattered throughout. They tell it how it really is, like this one (which you probably can’t read) titled ‘When Stakeholders Aren’t Supportive’.

Chartering the project

As part of the ‘how to do project management’ stuff, Biafore describes a project charter as a press release. This appeals to me as someone who writes press releases and I'd not thought about it like this before. She writes:

The project manager needs some publicity, too. Your authority comes from your project and its sponsor, not your position in the organisation, so people need to know how far your authority goes. The project charter is like a project's press release – it announces the project itself, as well as your responsibilities and authority as its manager.

There’s lots of practical advice like this, including the handy tip of not getting the most senior manager to send out the charter unless they actually know something about the project. You need authority, but you also need credibility, so choose someone who can give that to you, not any old senior manager in a suit.

"Like the pop-fly ball that drops to the ground as the third baseman and shortstop stare at each other, project work can fall between the cracks," she writes, whatever that means.

Getting technical: MS Project 2013

It's not until Part 2 that the book starts talking about MS Project. The biggest news since the product’s last release is that Project is now part of the Office 365 suite and there are easier to digest reports (which frankly wouldn’t be hard). In fact, there's a lot on reports which leads me to believe that getting them to look how you want could be tricky.

The book only covers the Standard and Professional editions, not Project Server. Some of the 365 suite features are covered but that software is evolving and the book is likely to get out of date quickly (and Biafore acknowledges that).

There are usability tips like collapsing the ribbon so you can see more of your plan on the screen and keyboard shortcuts. Biafore uses an example to create a basic project and then goes on to use another example to create a 'proper' schedule in a lot more detail.

She also includes tips on using other Microsoft products alongside Project, such as how to create a RACI matrix in Excel and importing resource names from your Outlook contacts.

The book is full of tips like how to create a resource and assign it to tasks at the same time, which are all aimed at getting you operational faster. I like the idea of downloadable worksheets for things like capital budget planning from the book's website and also links to MS templates online, which this book provides. They make the book more useful (and give it a longer shelf life) and the added resources will help you get your project on track more quickly. Having said that, I haven't downloaded any to try them out.

Check your schedule

There’s a lot about how calendars control resource and task scheduling with plenty of detail and screenshots about how to set up the correct variations of working time for your project.

As well as detailed walkthroughs and how to information, there is also practical advice for making the best possible schedule. For example, Biafore says you should be on the look out for these 8 things as you refine your schedule:

1. Task dependencies that shouldn’t be there or should be a different type.
2. Tasks with inflexible date constraints that they shouldn’t have.
3. Manually scheduled tasks that should instead be auto-scheduled.
4. Work or duration values that see too low or too high.
5. Work packages/tasks without assigned resources.
6. Summary tasks with assigned resources.
7. Overallocated resources.
8. Resource calendars that don’t represent people’s actual availability.

You can do some really advanced stuff, like setting work contours within an individual task to reflect how work is actually done – after all, resources don't work at the same pace for the entire duration of a task, especially if it lasts over several days. You could get really whizzy with your resource management using the advice in this book, but many of the features described will be far too much detail for the average project. While it's good to know what Project can do, it would be useful to have some sort of signpost in the book to say 'you can do without this feature if your project environment is not that mature or is relatively straightforward’. This would help new project managers work out which features they should use (like dependencies and baselines) and which ones they can leave and learn about another day (like creating an Excel form to display task information from Project and use it to get task updates from team members).

At over 800 pages the book covers a lot of ground. Much of that is screenshots, which are good and helpful. What surprised me was the breadth of the book, which covers everything from ‘what is a project’ to crunching some serious project calculations using data cubes. I don’t think you could read this knowing nothing about project management and turn into an expert by page 800, but if you need a detailed knowledge of MS Project 2013 then you certainly will get it from this informative and practical book.