Project management for virgins

 Written with the project management virigin in mind (including  a paragraph for the software first timer.)
We have far too much methodology in our lives when it comes to project management and when it comes to software lifecycles. That I have no doubt at all about, but that said, it is remarkable how many people are doing project management who don’t have the most basic grasp of what they are about and I hardly need mention the amount of enthusiasts clowning about with software projects.
If you are a project management virgin and keen to give satisfaction then here’s 7 tips that will help you stay on top
 1. Forget the command and control environment, this is different.  Reporting risks, raising issues and keeping important people informed the minute things look like going pear shaped is how you keep smelling of roses.  Don’t ever, ever be tempted to hide problems in the hope of fixing them quietly.  All you will be doing is taking ownesrhip of something that was never yours to begin with.  Now it is.
2. Make sure to agree and write down key priorities of cost, scope and time right at the start.  Record every day of slippage that occurs on the critical path and notify the customer and team, so you are not still being held to an unattainable end date.  Remeber this is a team effort, you are not the supplier.
3. Make sure time and cost estimates are dependable before setting them in your milestones. The best way is to try and make someone accountable for hitting them, but at least test them and question them and develop a plus or minus % as your best estimate of their accuracy.  Build in realistic slack based on these estimates.
4. Make sure that all the decisions are made by people who will then be accountable for them. Don’t do it for them. If a supplier says he will be late, get him in a meeting with the customer, remind the customer of the priorities he/she set out at the start, suggest the options available and ask for a decision. Make sure all affected parties are present and then minute everyones agreement.
5.  Don’t be bullied, state the facts clearly and place the responsibility for decisions on key stakeholders and minute everything.
6.  Break up the work into manageable packages and give them to people to copmplete.  Make sure you clearly explain in a document of some sort what is expected, when it is expected and what criteria you will use to judge it’s fitness.  Get rgeular progress updates and keep your nose to the ground for slippages.
7. Never take on project tasks at the expens of project managemnet. Better to report the slippage in a timeley way than to let you rown  work slip  while trying to do somebody elses.  This is how broken teams and broken organisations happen.
If you are a project manager about to nail your first software project, don’t neglect the foreplay, read this simple little guide first.
Software is’nt like procurig a new building, or renewing the fleet. These are all well understood products that change little if at all from decade to decade.
Software is only a few decades old and yet a long way from being a mature science.
Here’s why it is difficult.
Software replaces, or automates some process we are already doing in our work or life.  E.G academic research is now greatly assisted by Google and the internet.  CRM helps us manage the salesforce and supports our relationship with the customer base.
We all do these things in a different way yet any software system will force all users to work in one way.  To achieve this you need enlightened analysts who understand process, human beahviour, change management, and of course the vaguaries of systems. These guys are rare as the Dodo. What you will get is a techie trying to shoehorn you into the system he wants to build, or a supplier convinicng you that the perfect solution is the thing he happens to have in a box, or an OPS or Financial director who thnks you should be able to order it plug it in and get on with it.
Simple example
The HR director wants hot toasted sandwiches available to the field crews every morning.  He puts a junior HR person in charge of buying a toaster.
After a few very empowering meetings with the men form White goods inc  he delivers a toaster and calls IT to plug it in.
There’s no plug in the box and IT cant buy plugs without asking Finance to procure it, so a month later the toaster is rolled out.
The sandwiches are not eaten because the cheese in the middle is cold.  When someone put it in the toaster it set the place on fire.  IT were blamed and that was a narrow escape.
Now we are back to the drawing board asking what do we really want.  MPG plc are called in to handle it and they go “gathering requirements” from the crew. Soon we have a design for a new ktichen and stores with a walk-in fridge. Huge budget required and the project is rejected.
Finally the exasperted young lad form IT says, why not just have a specialist sandwich toaster from the cateriing shop and everyone gasps. A week later they are all eating toasies and the whole saga is forgotten except tha tis, for the project manager who presided over this debacle.
7 things to do that will give you a reasonable chance of success
  1. Agree goals and budgets to start with. Get ballpark suggestions and qutotes form everyoine likely to be helpful, suppliers, domain experts, online forums everywhere and make sure it is feasible.
  2. Check the customer’s assumptions that this is the right thing by consulting on detailed requirements with the people who will use it.
  3. Agree the final set of requirements and make sure you have a minimum set (that fits within your budget) and a list of ” like to have” requirements too.
  4. Make sure you don’t let anyone start designing the system, just stick to talking about the toasted sndwiches and let suppliers worry about the type of machine.
  5. Go find a reliable supplier who can commit to meeting those requirements and read all the small print very carefully
  6. Summarise the options and ask your team/ panel/ board/ customer to make the final decision.
  7. Make everyone accountable for their part from the requirements to delivering the finished project and build in a little slack.
You are not out of the water and ther’s still some work to be done, but at least you are starting from the right place. Knowing what will work takes you a long way towards a” hootin, screaming, wing ding of a great party”

Project managers must be consultants and must behave like consultants – it’s a bad day for “permies

Ed Taaffe has enjoyed a twenty year career in management with the past ten years spent in Project management and takes a special interest I human motivation as a management tool.  In this piece he explains why the consultant relationship with the client and the project team is critical to the success of projects.

This argument has nothing at all to do with the perennial  disagreements between Contractors and “Permies” in the IT industry, though it does go part of the way to proving the contractor viewpoint right.

What does success look like?
First let me be specific about the project failures we are addressing. There are all kinds out there and as any good problem solver or six sigma practitioner will tell you, there is more than one way to apportion blame and define cause.

What I am specifically addressing  is the high proportion of projects that get closed down,  or arrive late enough , or sufficiently over budget, or of sufficiently low quality to be deemed a failure.

These projects all started off wit everything in place and going fine, then at some point they began to drift and continued to drift unchecked until they ended up a failure.

My assumption is that since many projects defy totally accurate prediction of time and cost, there is a built in expectation that budget, scope and or duration may have to move at some point, if this is done and agreed then there is no project failure. Project failure occurs when the rot sets in and it is ignored, or when the project is set up with immovable boundaries and finishes outside of them.

Knowledge management holds the key

Within the technology world there is a particular inability to understand the nature of knowledge and it is mostly equated to data, or at best and not often, to information. The trouble is that neither of theses viewpoints is helpful.
 It is OK to believe that a  software process demands a precise piece of data to work correctly and to live in a virtual world of absolutes as do many technically minded people, but that doesn’t wash in the real world and there lies the corpse of many a CIO.

in the real world of doers, makers and shakers, decisions are made by people and the key ingredient is not the data, but the implicit and tacit elements of the way the people interpret information.

Bear with me, I’m almost done with the boring stuff.
Cognitive Dissonance

Leon Festinger produced a study in 1957 at Stanford University whereby he clearly demonstrated that when somebody has reason to present an argument that is actually at odds with what he believes, he naturally alters is opinions as a result and finds himself agreeing much more with the argument that he previously disagreed with strongly.

It’s not hard to imagine how and why this might occur and there is plenty of further work exploring this aspect of the phenomenon of Cognitive Dissonance, however the most interesting part of the experiment carried out by Festinger demonstrated that when a reward, or threat was used to force, or induce the person to argue against his own beliefs or judgement, then the effect of Cognitive dissonance was lessened, or missing altogether.

Clearly the mind has no trouble in understanding the idea of being paid to hold an entirely objective opinion, which it seems almost incapable of achieving under other circumstances.

Implicit and tacit knowledge

Interpretation of information and comparing it with learned responses and experiential knowledge and bias is the essence of implicit and tacit knowledge. It is therefore critical, naturally that the information is interpreted in a fairly objective way if the resulting knowledge is to be accurate and reliable and good decisions made.

Take the situation where the project manager has been indoctrinated and reaffirmed again and again that the project is on schedule and will not fail, or will not slide and he has sent out the RAG reports and made reports and presentations to stakeholders and boards convincing them that everything is going well, how do you expect he will react to data, or information telling him that several key tasks have slipped and there are issues looming?

It’s all in state of mind

The fact is that if our project manage is part of the culture and one of the pack and he feels the pressure to make this project a success, he will convince himself so strongly of this that he will behave exactly like Festinger’s students did in his experiment back in 1957, he will fail to see, or assimilate that which contradicts what he has been told to believe by the peer group, that which is contradictory to the crowd consciousness.

The answer is simple

The project manager must be an independent consultant and he must be a facilitator only.
He must have no personal stake in the success or failure of the project in terms of hitting dates, amounts, or quality targets, but he must be someone who talks straight, keeps the “permies” honest, ignores the crowd pull and tells the Empror when he is wearing no clothes.