Saturday, June 13, 2015

About Planning

Here's a little something that I was reminded of recently. (Not that everything in this post occurred recently, but I was reminded of it).

I wear a lot of hats. Sometimes I'm a project manager (PM), sometimes a functional analyst (FA), sometimes a technical analyst (TA), sometimes a programmer/analyst (PA). Occasionally I'm acting in the role of quality assurance (QA) tester, or even in a purely consulting role. Sometimes its several of these, and sometimes it's all of the above.

I'm often asked to estimate project work. This puts me in an analyst role on behalf of the programmers. Now, estimation is often described as a "black art", but there are a few things that project managers should always remember. These are not exhaustive, and are not in any particular order. And I'm not going to talk in terms of some particular methodology. This is simply some common-sense advice that you can apply anywhere.
  1. An estimate is just that. An estimate. It could be wrong. It could be high or low. Even when it's a fixed-price quote, it still carries the risk of being wrong. And while we'd LIKE estimates to come with an assurance of a certain accuracy, there will always be the possibility that something will reveal the work to be more difficult than originally envisioned. Usually, but not always, this is some hidden requirement. The more precise the requirements are, the better the estimation will be, so when an estimator comes back and asks for clarification of the requirements, you as a  PM should jump at the opportunity to clarify those points.
  2. Likewise, if your estimator comes back and tells you that you missed some necessary requirements, the overwhelming probability is that you missed some necessary requirements. If somebody gave you some "high level" estimate that didn't take these necessary requirements into account, you don't have an option. Throw that out and go with the new information. Because...
  3. Disappointing your customers is only possible if their expectations are not met. If they HAVE measurable expectations in the planning phases of a project, then you probably made premature promises. STOP THAT. If you did it anyway, then disappointing your customer once an estimate is returned may be inevitable. If so, it is far, far better to disappoint them in the planning phases when something can be done about it and meaningful decisions can be made than if you disappoint them at Acceptance Testing, when the only option is failure.
  4. Image by Alex Prolmos
    via Flickr
    1. Necessary requirements that are often missed often
      include such things as regulatory governance and technical necessity. They can't be skipped, and they're not free to implement simply because you forgot about them or didn't know about them. They also include things such as the requirements of previously unidentified stakeholders who can block a project well into the execution phase, after a sizable chunk of the budget has been spent, so that their requirements are inserted into the requirements.
    2. Informing the project owners of these new requirements as early as possible allows them to properly revise the requirements, re-estimate the work, and re-budget. That's not a bad thing. It's how projects are done. Also, it gives them the opportunity choose not to do the project because it will prove to be too expensive or difficult. That's not a bad either, and it's not failure. It's a good decision not to waste resources. Don't mis-cast it as something it's not.
    3. Failure to communicate this new information early results in a project that will never be implemented because it doesn't work due to erroneous assumptions, despite coming in on-time and on-budget, meeting 100% of the requirements.
    4. "Failure is not an option" is the dumbest thing that could ever fall out of the mouth of a project manager. Don't ever say it unless you deliberately intend to sound inexperienced. Failure is always an option. Part of the job of a project manager is to ensure that if the worst happens and something does fail, it does so in a manner that does the least damage. There should always be planning for failsafes. "Failure is not an option" is just an expression used to advertise that you don't want to do the hard work of project management. Always be able to answer the following:
      1. What's our fallback?
      2. Describe the procedure for rollback.
      3. What business processes can work around a problem?
    5. By the way, I realize that some people think that "failure is not an option" is a clever way of saying that you want people to treat the project with importance and work hard. The problem is, it's not clever. Tell the people what you want, clearly. Idioms and clever sayings will only be misunderstood by various members of a multicultural project team.
  5. "Definition of work" is not done in the estimation phase of a software project. That's why you set aside time for Functional Design and Technical Design. What you get at estimation is a very, very high level guess at the areas that need to be changed. Determining exactly how they will be changed requires further planning. You've allotted time for that, so exercise a little patience and define the details in the time reserved for doing it.
  6. A work breakdown structure (WBS) is a method of defining a project's scope. "We're going to change these things", or "we will provide these outputs". It doesn't define how you're going to accomplish that work. It doesn't tell you the detail of the work itself. It doesn't tell you the time required to do it.
  7. Proper scheduling can only be done after the work has been defined and estimated. 
    1. If you've created an implementation schedule before you received your estimates, you're doing it wrong. An estimate is NOT "wrong" if it doesn't fit into your Fantasyland expectation of when you'd like to deliver, or how much you'd like to spend. Insist upon it, and you will only prove that failure is an option. I like to quote Bruce Willis in "Armageddon": "We cannot use your Air Force personnel-only drill time card!" You asked for an estimate; you got an answer. Use it. You can negotiate on specs or deliverables, but in the end the work takes as long as it takes.
    2. You cannot plan for 8 hours of work in an 8-hour day. There are meetings. There are other projects. There is support work. There are holidays and vacations, medical and dental appointments, parent/teacher conferences, etc. This overhead is different for each person, but it always, always, always exists.
    3. When your people bust their butts in order to meet an unreasonably tight schedule, you'd be wise to show some tangible appreciation. They are going to remember their effort, and if you don't, you can expect that's the last time you'll ever receive it.
Many of these issues... scheduling, disappointing your customers, etc.... come purely as a result of failure to patiently do things in the right order. You want to get a schedule and a budget and approval, etc., and so you make some back-of-the-napkin plans before formally defining the scope and requirements and getting estimates from the people who are skilled in delivering the final product. This in itself isn't terrible.

What is terrible is the failure to realize that all of that sort of planning simply represents desires and wishes, and not what can be reasonably delivered. You can demand all day long that these daydreams of the future "must" fall within 30% of a final estimate, but that means exactly nothing when measured against reality. Often you must simply pay more, adjust your requirements, or choose not to do the project at all. The only question is whether you'll do it voluntarily.

0 Comments:

Post a Comment

<< Home