Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Category Archives: Cartoon

Is ‘No Estimates’ for real?


No Estimates is a concept that I had not come across until very recently. The basic premise of No Estimates is there is significant inaccuracy in software development estimates. Even when you spend a lot of time estimating, it is still not necessarily accurate enough to give you an exact picture. Therefore, the time spent estimating does not give you a reward for that effort. Proponents of No Estimates argue you may as well spend that time and effort into understanding what the most important feature is to the user and concentrate on getting that delivered well. Once delivered, you concentrate on the next most import feature and so on.

Is No Estimation for real

When I first read about it, my initial reaction was it was like throwing the baby out with the bath water. Just because we are not as accurate at estimating simply giving it up seemed like lunacy. On reflection however, I can see it being useful for in-house teams that are supporting a business application. There the organisation has already seen value in continuous improvement and has accepted the software developers as part of the package to deliver the business outcome. You can concentrate on small measurable improvements to the application as directed by business. The users in this case are well versed with the application and are able to explain the desired improvement. Interestingly enough, in my experience this type of development is comparatively easier to estimate than others.

I also had a thought that product development teams may be able to use this in some manner. The rationale was they have quite a bit of control in terms of what they can cut out of scope if something turns out to be more difficult than initially perceived. However, the tradeoffs they make are not necessarily linear. There is usually not comparison that you can unilaterally say is feature A versus feature B. Feature A may very well be more important, only if it is likely to  be no more than 20% more in cost. No Estimates as a concept is not well geared to help in this scenario.

Even in scenarios where No Estimate is a reasonable course, I see significant risk of what I call ‘design blinkers’ – only taking into account the immediate requirement(s), rather than an overall view to limit rework. Design blinkers happen in all form of software development. This is because you can only design for your known scope. By limiting your thinking horizon to the next most important feature, you are in effect likely to encourage less holistic design.

From the reading I’ve done so far, it appears there is a level of misunderstanding in what estimates are used for in projects. There are no perfect estimates – projects are by nature risky. You can only ever be expected to deliver estimates with complete accuracy early on. They should get progressively accurate as you go through the various phases of the project. Initial estimates to judge whether the client has the cost appetiate to even embark on the journey, then further refining to understand whether your organisation can execute the project safely with a level of profit. These estimates will be less accurate than your feature level estimates, that you will be building up when the project goes into execution. In most cases you use multiple methods of estimating than simply a combination of all the features – previous track record, comparative scale with other similar projects and some level of feature based estimation.

In my view there will be very few situations where you can get away with doing no estimates and be able to make the decisions you or your customer needs to make. The answer is not to avoid estimating, but estimate at the level of accuracy that is required to make the decisions. Never estimate $X or hours Y. Always clearly state estimates with their level of accuracy i.e., $A to B or hours Y to Z.

Image Credit: Dilbert (Scott Adams)

Sh*t ‘Agilists’ Say


My two cents worth

As an Agile coach I’ve had the pleasure of working with some of the best minds in the IT industry over the years. Unfortunately most of these individuals remain unsung heroes throughout their careers. But fame or recognition isn’t what drives these individuals, instead, it is the satisfaction of producing unique solutions to complex business problems day after day that keeps them motivated.

Being human beings however, even the best of us get frustrated, angry, agitated at times. In fact in all of my 8+ year career, I have never seen a team be able to avoid the storming phase from the  ‘Form-Strom-Norm-Perform’ cycle. Some have bridged the chasm quicker than others but all teams that I’ve worked with have had to go through this cycle.

My job as coach is to be there for my teammates through their team building journey; help them re-configure their mindset, encourage debate, encourage criticism while keeping emotions and ego out of conversations, enable…

View original post 1,366 more words

Hitler implements SAP

Things Project Managers Say

Official Dilbert Widget

%d bloggers like this: