I speak software.NET

   Have you ever wondered if estimating a software development project really matters? I mean, comeon, anyone who has ever been on an app dev project of any significance knows what I’m talking about. Have you ever been on a project where the estimate was accurate and where ultimately the client received all the features they asked for, in the time frame they wanted with a reasonable degree of quality? For me the answer has consistently been no unless the project itself was not very significant.

   What has happened is either we ran over budget, ran out of calendar or we delivered with poor quality. Now why is that? My current thoughts are that the people that performed the original estimates were not able to account for the complexity of software development. I thought I’d list a few dimensions that can impact your team’s meeting the estimate.

Some Factors involved in missing a deadline:

• Analysts/Developers don’t understand the domain
• Hired people on the team later than expected
• Hired people on team earlier than expected
• Lot’s of turn-over
• Bad Hires
• Client refuses to prioritize requirements
• Client refuses to stop asking for items that add little or no business value
• Client requests constant demo’s for various interested parties
• Client insists on “working” demo’s
• Developers are waiting on architecture decisions
• Change in source control provider
• Change in source control structure
• Integration project where integrated technology is not sourced promptly
• Integration project where the integrated technology is immature and not well supported
• Use of new ”buggy”technology
• Use of new “not well or un-documented” technology
• Business analysts not held accountable for slippage but rest of dev team is

These are just a few factors, there are literally limitless reasons why an app dev team can fail to meet initial expectations. But why talk about this? So we can learn and adapt for the next time.

 With all the pm methodologies out there that claim to be the answer to app dev manager’s sleepless nights, why do team’s still miss the estimates. And yes I really mean deadline . My thinking the answer is that there are too many factors a dev team manager simply can not control. Look at the list again. Did you notice some of the items are things you couldn’t control if you wanted to? How can any methodology claim to deal with that? At best, if the method is good. You can discover earlier that you’ll be late and be able to communicate that to your client and that is a good thing. At least better than mentioning it the day before the app is due. But my assertion is this… there are factors involved in application development that simply can not be conroller and therefor we may never be able to develop a methodology that can guarantee an application is delivered on time every time. The better methodologies will let us discover this sooner and therefor adapt to the situation – usually by taking out features that were really not necessary in the first place.

 The hardest part of developing software is managing the expection of the client … and this starts with the estimating process. Now looking at the list again, let’s take it apart. We can start by examining those items that can’t be controlled vs. those we do have some level of control. We will then assign each item a weight which represents the probably of this being an issue on the project. When we’ve completed this task, we can identify a risk factor for the project as a whole and come up with an estimate as a range.

Now I know what your thinking. A range? And just how am I going to get that by my client. We all know client’s are not looking for a range. They want a stop loss … a not to exceed figure. Well, I get you. My answer to that is that as professional developers, we need to put that burden on the folks that are selling our services. We can fine tune the development process all we want but if we don’t start with the causal relationship between the estimate and the process then there’s only so much we can do.

 Let’s pretend that in our fictitious company everyone agree’d to this principal. What then? Let’s say we  identified 20 possible risk items, as we identify that we are realizing risk items, the PM would simply document that fact and the estimate would automatically increase. The difference being that all the stakeholders of the project would have already been prepared for that as a possibility.

The reverse of this dynamic is what happens today. The dev team is asked to make up for the realized risk item somehow. Ultimately, this is often not possible because the project’s resources were already strained in order to make the best possible profit possible. So what does all this come down to. It comes down to expectation management. If we include these risk items in the estimate, we are better manging our client’s expectations.