Antacids for the PM

PMs, can you imagine the look on the faces of those developers when I said that they needed to supply you with things like estimates and time sheets?  I bet some of them were knocked off their feet!

I mean it’s not like you were asking them for anything difficult.  I mean, how hard can it be to create an estimate for a project?  It’s not like it’s rocket science.  Every developer should be able to do it.  I mean, the National Gun Registry hit it’s target.  Well, maybe it didn’t.  Well, what about the Denver luggage handling system?  Another fiasco?  OK, the FBIs Trilogy Project, now that was … a disaster?

Everybody can look into the past and come up with failed estimate, but sometimes, the Project Manager does it to themselves.  This may be a shock for some of you, but sometimes Project Managers are under different pressures than you realize.  Back when I was younger I worked for a consulting company.  My job was to come up with the technical work plan and estimates for the projects the local office undertook.  I would then, using historical data and some darn fine guessing, come up with what the effort would be on the technical staff for the project (technical staff meaning project DBA and internal technical support). 

One of my proudest, and saddest, estimating moments came for a relatively simple business project that had a number of interesting technical complexities.  My estimate of the technical cost was 179 days.  When combined with the other parts of the project it turned out that this simple application was going to cost the client a lot of money.  In an effort to reduce the impact tot he client the scope was shuffled, but this did not reduce the technical effort that needed to be spent, so in a classic PM moment the number of days was arbitrarily reduced to 79.  I am proud/sad to say that this is one of the few times in my life where I was dead on with regard to the effort.

Project Managers, if your team says that something is going to take a certain amount of time, ask them questions, make sure they understand both the problem and their own estimate, but don’t arbitrarily change it unless you know for a fact it can be done for less.  The odds are they understand what needs to be done better than you and by changing their estimate you are telling them that you don’t trust them.  If you still feel the estimate is high, have them sit down with you and walk you through the estimating process they used.  But, if the numbers still add up to something you don’t like, take a tums.

Oh, That’s Easy — Part 2

“Oh, that’s easy.”

As a project manager I hated those words, particularly if they were coming from my technical team. The more technically adept a person is the more inaccurate the person is at coming up with estimates. Yes, there are exceptions, but they are few and far between and should not be counted on at all times.

Someone who is familiar with the technology and lives and breathes the code is someone who is going to be horrible at coming up with estimates for other people. Heck, they are even horrible at coming up with estimates for themselves. I have had the privilege of working with some very talented people over the past 25 years (damn, there’s that age thing again) and with the rare exceptional circumstance, every single one of those people has problems with estimates.

So, how do you compensate? First of all you need to ensure that the developer has thought of everything. Most of the time an estimate only includes the raw time to develop the code, but not to test it, document it and ensure that any technological innovations are compatible with the existing environments. You need to keep track of this persons estimates and use previous estimates in guiding your decision about current estimates.

No, don’t create the estimate for the developer as you probably don’t know the technology. (See yesterday’s note.) Understand, however, that the developer is going to be optimistic about his part of the solution so you need to take his estimate, inflate it, and come up with something that is realistic for the project. And, the most important point of all, keep track of previous estimates and how they matched reality. As mutual funds state “Past performance is not an indication of future results”, but they’re probably darn close.

Oh, That’s Easy — Part 1

“Oh, that’s easy.”

As a developer, I hate those words, particularly if they are coming from the Business Analyst, Team Lead, or, worse of all, the Project Manager. To be brutally honest, and when have I not been, most Project Managers are not familiar enough with the technology being used on a project to actually make that decision. Most, not all, but most project managers are more in tune with the business aspect of a project, but not the technical parts of the project.

A number of years ago on a large project I was brought into a meeting with the client and asked whether something or not could be done. My immediate response was “I’m not sure, but I think we can.” This was immediately translated into “See, it’s easy”. Afterwards the project manager came up to me and asked me if I could have it done by the next meeting, in two weeks. When I told him I could have the estimate ready in two weeks he came back with “Oh no, you misunderstood, you’re going to have the solution in place in two weeks.”

Needless to say, no one was happy. The solution wasn’t in place in two weeks, so the users were disappointed. The solution wasn’t in place in two weeks so the Project Manager was angry. I didn’t get the proper support from the Project Manager so I was quite disillusioned. (OK, I wasn’t that disillusioned because I didn’t expect anything else, but I didn’t fill out the patent application either.)

The lesson I learned, and that I hope I have communicated, is that Project Managers should never give an estimate of the technological complexity of a request without first asking their team. It’s a wonderful recipe for disaster if you do as no one is going to be happy, least of all the client.