Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to John D Carmack and Random Acts of IT Project Management with appropriate and specific direction to the original content.

Posts Tagged ‘Risk Management’

It happens to everyone sooner or later. Someone made an error in giving an estimate on a task or set of tasks. The causes can be many. Sometimes, the estimate might be fatal to the timeline of the project. How can this be avoided?

Erik Eckel of TechRepublic says that his “Three tips for avoiding project estimating mistakes” are: 1. Confirm all assumptions, 2. Don’t expect trouble-free projects (aka plan for “unknown unknowns”) and 3. Specify exactly what estimates include (aka put it all in writing). He goes into each of these in his article.

The Defensive Mentality

I’ve been an advocate for “defensive programming” for years now. Developers are notorious for being overly optimistic. They can’t fail. After all, it is their code, and their code always works, right? I know this attitude to be true. I was a software engineer myself for a while. Needless to say, my code did not always work right the first time. I had to learn to expect that something will go wrong and plan for it. Just like the driver learns defensive driving and plans ahead because accidents even to good drivers, the developer must plan for strange inputs and react accordingly. The developer needs to come up with a test plan before coding. The assumptions should be stated not only in design documents but also as code comments first.

I know what you are thinking, as I have thought it myself: That is going to add a lot of overhead to the project. The plain and simple truth is that it reduces effort on the project. Sure, your estimates will go up. Sure, management is going to question why a module takes so long to code. The answer is that it actually reduces coding time and, better yet, wasteful time produced by context switching, because there is less rework! It puts the effort closer to the front of the project, where it is cheaper. Have you looked to see how much rework occurs on projects? How much of this was even planned? Wouldn’t you like to reduce it, planned or not?

The project manager needs to be aware of this and prod people to adopt a defensive mentality. Basically, when you look at Eckel’s three points, they boil down to being “constructively pessimistic”. In other words, you expect bad things to happen and plan accordingly. Even if you use defensive techniques, the PM needs to be pessimistic too and build in rework for a project. To reword Eckel’s list slightly, the PM needs to challenge assumptions (pessimism that assumptions, particularly about inputs and outputs, reflect reality), not expect lack of problems (general pessimism that all will go as planned without any unit testing and without any rework) and be specific in communication (pessimism about understanding and being clearly understood).

No Fear

Eckel actually has a 4th tip, though. Near the end of his article, he states, “Analysis paralysis isn’t just for politicians and leaders in other industries — it affects IT managers as well.” Fear, in his view, makes you less efficient. As we discussed yesterday in “Keys to Successful IT Projects”, this fear can lead to not making important decisions that would otherwise make the project successful.

So, while I advocate a certain amount of pessimism, don’t make the mistake of rooting the pessimism in grid-locking fear. Constructive pessimism, however, simply acknowledges that things will likely go wrong and forces you to make a plan for the event.

Of course, you should plan for success as well. After all, if you are being constructively pessimistic about your constructive pessimism, you’ll also realize that some things go right, so you need to plan for those events as well!

OK, I’m teasing, but only slightly. Each event will either be a success or not. What do you do if A goes according to plan? What do you do if A does not go according to plan? Always have a back-pocket plan if something of significance doesn’t work out.

Reality Check

Developers are notorious for being overly optimistic. I have found that many infrastructure engineers are just as optimistic. They don’t plan for failure, so they don’t know what to do when it hits them. Many PMs have come up from the technical rank. Unfortunately, these PMs sometimes still carry much of the same optimism they had before.

“Constructive pessimism” is the antidote to naive optimism. Naive optimism doesn’t plan for things to go wrong at all. Constructive pessimism says things will go wrong, but here is what we will do about it. It provides a reality check to the team.

The funny thing is that this actually increases confidence in the overall project because contingencies have been identified that provide a safety net for the team.

We’ve all seen the ads: “Wanted: Hands-on Project Manager”. I’ve even seen one that read something to the effect of, “This is not just an admin position.” And, let’s face facts, shall we? Some PM positions are basically bureaucratic paper-pusher positions. So, the sentiment is understandable. I also believe that most PMs are not like that.

That being the case, why does an ad like the above scream, “Run for your life! Danger, Will Robinson! Danger!”?

I truly believe it comes back to different interpretations of “hands on”. Like I discussed in the post “Why the Role of Project Manager is Different”, “I consider myself pretty ‘hands on’ because I run the project. I question people’s timesheets. I ask them why things are taking so long. I interfere and get them help if needed. I do EVM calculations whether you ask for them or not (because it helps me do my job). Do you want me to code? Then you are not looking for a PM.”

“I just want to be told what to do and when,” says Kevin Kinsella, IT Regional Manger based in San Francisco. “The best project managers that I have worked with have been able to keep the project on track by telling me and the team when things were due or what may need my immediate attention.”

Kevin is not alone in his view about what distinguishes a successful project manager from the rest. Successful project managers are able to provide their teams and management with a proactive and hands-on style of managing and communicating that ensures their overall projects will succeed. What I call active project management or APM.

APM as a consistent style is elusive for many project managers because they generally don’t see themselves as passive; even though their team does. In many cases, that disconnect between the project manager and the team is not realized until after the project is completed―and then it’s too late.

That, to me, is being “hands on”. PMs who code are not “hands on”. They are distracted. Unless the project is small, the distraction may cost the project.

One of the leadership principles that I learned early on in the Army that doing grunt work eventually distracts from what you really are getting paid to do: Lead others to accomplish the mission. Being in charge (I mean, really in charge, not just be handed a title) means you have to be fully engaged on multiple items at the same time. This was before “multitasking” became a mainstream word. You are already multitasking, so why take on additional unneeded distractions?

Notice, I said “unneeded”. In order to meet the deadline, you may have to get down with everyone else and shovel some dirt. You may have to sacrifice some in your oversight in order to get the main mission accomplished. However, you do so at the risk of not being in position to observe other activities going on. Those other activities may or may not come back to bite you.

Those are the trade-offs. Knowing what trade-offs to make is part of good management skills. You weigh the risks. The more project tasks you take on, the fewer management tasks you are doing.

Remember when you learned how to drive, and you had to take a course called “defensive driving”? You learned to anticipate problems on the road instead of racing down the road assuming nothing would ever go wrong. By driving in a manner that would put you in the best position possible should something go wrong, you often avoided anything going wrong at all.

Software developers tend to be an optimistic bunch. Write code for that? No problem! Want it in a week? No problem! Somehow, they tend to underestimate the power of a computer to do only exactly what it is told to do, whether by their own code, someone else’s they have to interface with or the compiler.

Agile development encourages people to do their test cases up-front. I am in complete agreement with that concept.

There are problems with that, as there are with anything in life. In “Developers Can’t Test for Toffee!”, Kelly Waters asks, “Why is it that developers can’t test?” Waters pretty much states it is the “can’t see the forest for the trees” syndrome. Developers can only test for issues they think of. They are down in the bowels of the code, so naturally testers can think of scenarios the developers have not.

Waters makes a pretty good case, I think. However, my experience is that most developers aren’t trained to think about what goes wrong. I remember more than one post-mortem where I would ask, “Why wasn’t this accounted for?” and the answer very often was “I never thought that [condition] would occur.”

I guess I was fortunate in that I had a professor who insisted that code ran and produced the expected result. “Code for the error conditions first,” he used to say. “Think about what will happen, because it eventually will, when you get in some bad data. Don’t assume users will input valid data.”

I began to call this concept “defensive programming”. Anticipate the problems before the best case scenario is even written.