Mike Ellison

Hmmm… would my project look best in Chanel or Hilfiger?

Actually that’s not what I mean. I’ve been reading The Genius of Design by Penny Sparke. I like to take one concept (in this case the design of physical objects) and apply it to another field that on the face of it isn’t related at all – the abstract concept of a “project”.

One core concept from the book is the separation of the act of design from the act of construction. What had previously been executed simultaneously by an artisan was now separated. Where we are at the moment in project management is the artisan stage. Yes, Project Management Offices try to bring some kind of order to the individualism of project managers but the requirements that enable division of labour have not yet been met. The design of a project cannot easily be separated from the project manager. This is not the same as having one person plan the project and having another person manage it – the latter will pick and choose what they keep through necessity. So, the design of the project must be able to withstand the shocks and bumps where the ship of management dreams is facing the rocks of reality.

It struck me that the weak-point is that currently within the vague realm of “planning” the design of the project is implicit. Some things aren’t so hidden such as the communications plan but other things are mixed-in with the details of how the product of the project is going to be created i.e. they are too implementation-specific.

The problem with implicity (or is it implicitness?) is that things tend to happen without thought. Luck starts to overtake judgement in the way that the project functions. Also the design of the project is hard to review as a singular entity and that makes it harder to evaluate whether the project is going to “work”. I think that it is important to be able to view the project as a designed mechanism rather than a collection of processes thrown in a box.

Apart from having a nice clean concept of the project in the project manager’s head and the project documentation, the benefit of having an explicit design would be that it is easier to communicate to the team and stakeholders so that they understand how the project is going to work and where they fit into that.

What I would like to see is a generalized design that can be re-used for different projects e.g. the weekly cycle is already defined. Then it is a question of adding in the project-specific layer. This is not the same as adapting the plans from previous projects. There should also be reduced risk of missing important items.

More thoughts on this as the concept solidifies. However it’s not just an intellectual exercise. What I want is to have a standardized design that I can apply to all my projects so that set-up is swifter and it is possible to predict a level of performance.

…Mike.

Just as there needs to be a better word for “positive risk” – the risk of benefit or opportunity – there needs to be a better word for “negative assumption” i.e. assuming the worst. This extends my earlier posts on assumption (http://iqi616.com/2011/01/assumption-is-the-mother-of-all-mess-ups/) and risk (http://iqi616.com/2011/01/risky-business/).
 
When compiling lists of assumptions we are usually looking out for assumptions that might trip us up by turning out to be false in a bad way. That is to say, we focus on identifying the assumptions which assume that something is going to turn out for the best. But don’t forget that we often also assume that things will turn out for the worst. These negative assumptions can also turn out to be wrong. An example would be assuming that the City would not allow you to hold your rock music festival in one of the public parks.
 
So, you need to be just as careful to identify implicit negative assumptions and make them explicit and document the corresponding risks and mitigations in the same way you would handle positive assumptions. Taking the example of the rock music festival, you might not even have thought to approach the City council to see what they have to say about it. If the City hasn’t already stated that they don’t allow music festivals in their parks, you couldn’t know for certain without asking.
 
There are two benefits to identifying negative assumptions… You will have a plan for what to do if things go too well so you won’t end up with a situation where you have all the parts for a project but no team to put it together. But most importantly, you will be ready to take advantage of any opportunities that open up to you.

…Mike.

No, I’m not talking about using Adobe Photoshop® to make your project appear more successful. It strikes me that an important part of project management is converting a project full of colour and nuance to black and white. And I’m not talking monochrome either. This is pure black and white. On an image you achieve that using the Threshold tool and you often have to pre-process the image to get what you want because the tool is so unforgiving and will only give you black or white – nothing inbetween.
 
To manage a project you have to obtain clarity of status… Done/not done. Ready/not ready. Complete/incomplete. Pass/Fail. Approved/not approved. Fuzziness may be attractively expedient but at some point you will find the project moving ahead when it shouldn’t. You might get away with it but if you don’t, people are going to start asking you awkward questions. The only way to handle fuzziness is to find an acceptable threshold for “good enough” to convert it into yes/no.

For a long time I always felt sorry for people working hard on a task where it’s taking a long time to get from being “almost ready” to “done”. It seemed unfair when tasks were recorded using the 0/100% rule. They weren’t 0% done, they were 95% done and with a little luck would be finished very soon. But then I started seeing things from a customer perspective – incomplete is incomplete. If a deliverable has not been delivered to the customer, the customer has received 0% regardless of how close to 100% the deliverable is.
 
I was once part of a project team where a go/no-go was allowed to pass because the team was “almost ready” and no-one was brave enough to re-state that as “not ready”. That was a big mistake that took months to recover from. So, that added another binary decision point and I now had a list!
 
Adding pass/fail for test results to this new list of binary decisions was a no brainer and that led to a growing awareness that careful design of binary decisions brings clarity. The design of each binary test must be careful to avoid inappropriate results but I can see that effort is worthwhile. It puts the project manager in a position of strength. You can say “Yes, because…” or “No, because”. If particular stakeholders are unhappy, they will be forced to argue for a change in threshold that is acceptable to the other stakeholders. Either that or they will have to over-rule the project manager and by doing so will be responsible for the consequences.
 
So, how do you track these thing? Checklists are the easiest tool. A readiness checklist will have all the criteria listed with a Yes/No box for readiness. If any of the criteria are No, the overall status is also No. I have found that this really focuses attention on the criteria that are status No. It also helps you obtain the assistance of major stakeholders. They might be attention deficient but they can understand that No is bad and will push for whatever is needed to convert that to a Yes.
 
To summarize, when you see fuzziness take a positive step to convert the issue into black or white by finding a way to define a valid threshold that will make any decision into a simple Yes/No. Ask yourself and the stakeholders what is needed to get over the problem and take a step forward.

…Mike

One of the things with being a project manager is that some people try to use you as a buffer. They never seem to want to communicate directly with each other. Carol needs a report from Fred, so she asks you to ask Fred to give you the report. Fred knows that it’s Carol that needs the report yet he sends it to you for you to give it to Carol. That wouldn’t be so bad if there weren’t a bunch of other people trying to do that and it would be even less bad if you weren’t away on vacation!
 
Not only does that behaviour make you a bottleneck, you are also taken away from the project management work you should be doing.
 
When this happens to me, I politely say that information flows faster round me rather than through me. I just need to know that the action happened – I have no intention of reading Fred’s report unless it is pertinent to my role as project manager. In RACI terms, I’m just an “I” – I only need to be Informed because I am not Responsible, Accountable, or Consulted on that report.
 
The only time you should be a buffer is when there is a specific need to do so – e.g. a personality clash between the customer and one of your key geeks and you can’t afford to lose either of them.
 
So keep an eye out for when you are being placed in the flow and take action to have people communicate directly with each other and just inform you of the result. Be especially vigilant for people that are using you as a buffer to buy themselves time with the plausible deniability of waiting on you!

…Mike

Last time, I wrote about assumption not being bad but actually a desirable technique for overcoming analysis paralysis (http://iqi616.com/2011/01/assumption-is-the-mother-of-all-mess-ups/). This time I’m going to tackle another aspect of project management that has negative connotations that need to be revised. The R-word: Risk.
 
Risk always seems to be viewed as a bad thing – especially in corporate projects. At best there is the strange concept of “positive risk” i.e. the danger that something might turn out good when all expectation was that it probably wouldn’t. These days, whether in business, parenting, or walking in the park, risk is seen as something to be eliminated.
 
And then there’s the calculated risk. Again something that implies something dodgy took place – someone trusting to luck instead of judgement (despite the use of the word “calculated”). Why is that? Surely a calculated risk is a reasonable thing to do – as long as the calculation is sensible. Part of the problem is that people don’t like to tell other people that they’re taking any form of risk so the risk takers only admit it afterwards. The problem with that is it doesn’t change anyone’s view on risk – they just breathe a sigh of relief they didn’t have to pick up the pieces.
 
Let’s take a look at history. What about sailing ships and their trips across the Atlantic and around the globe? What about the moon missions? Huge risks but calculated and mitigated. Even less dramatic adventures involve a certain amount of risk that if mitigated render the risk acceptable. Take flying, the risk seems higher but so much mitigation takes place that you are very much more likely to be killed in the car taking you to the airport than the plane flying you to Paris.
 
So, the same to risks in projects. What is wrong with saying “we are going to take a risk, this is the payoff, and these are the potential pitfalls and these are the mitigations”? Don’t avoid discussing risks, bring them up-front and show that the risk has been properly handled.
 
Far from being bad or even neutral, risk can be good. I’m not a great adventurer but risks are exciting and when carefully presented a risk can capture the imagination of the team and stakeholders and help get them excited and engaged. Thinking back to my earlier post about using the word Ambition instead of Vision or Goal (http://iqi616.com/2011/01/revelations-about-project-management/) why not make the risk part of the ambition? Don’t hide from it. Lay out the risk from the outset and highlight the payoff and the mitigations.

…Mike

Assumption is the mother of all mess-ups

That’s a cleaned-up version of one of F1 team-owner Frank Williams’ favourite sayings.

My second revelation over the holidays is that it is only implicit or taken-for-granted assumptions that are a problem. Explicit assumptions, on the other hand, are completely different and a useful tool for the project manager.

Like many words in project management, “assumption” has all sorts of connotations. If you like, we make all sorts of assumptions when we come across the word “assumption” and not all of those are favourable.

Assumptions are a way forward. Used intelligently, assumptions can get you out of analysis paralysis or at least give you a start on a project. If you don’t know something for certain, can you make a sensible assumption that will enable you to move on? Even the whole project needs a fundamental assumption that it is possible to succeed.

Now, you have to remember that every assumption has a risk, so for every explicit assumption you must have an explicit risk and risk assessment. For example, you can assume that the city will give you permits for construction but you need to address the risk that the application will be delayed or denied. You don’t want to hold everything up until you actually get the permits so you proceed with the assumption you will get the permits and a risk assessment of the chances that you won’t get the permits.

Final point… going back to implicit and taken-for-granted assumptions – you need to have at least one attempt at identifying them and making them into explicit assumptions so that you can handle them properly. You also need to keep a watch out for any that crop up while the project is in progress.

…Mike