quantmleap

Bob Cravens has a fantastic post about estimation in a software development domain. Contrary to others who attempt to come up with reasons why estimates are a waste of time and cannot be legitimately done, Bob articulates a practical and logical path through which estimates can be done in a sensible and credible way.

Bob suggests the following ‘principles’:

• Estimates require domain knowledge.
• Tasks with a large size (or effort) are harder to estimate than smaller tasks.
• Uncertainty decreases as we gain confidence and understand our abilities.
• Uncertainty continually decreases as we get closer to the finish.

Now, not everything in Bob’s post is to my liking. For instance his comment that “First let’s spend some time discussing how we determine the size of the features we must estimate. We must learn from the past and not fall into the trap of the waterfall development process” is bizarre, to say the least, as it is not clear what trap he is specifically referring to. Does he suggest that the waterfall development process does NOT learn from the past? Do I really need to elaborate why this is non-sense?

Apart from this and perhaps one or two other Agile self-righteousness observations, the principles outlined above are as correct in Agile project as they certainly are in non-Agile projects. The notion that estimation is either not required or alternatively not possible is clearly debunked.

Think about it!

Recently I have been involved in heated debates on Twitter (and also in comments to an earlier post) with proponents of the #NoEstimates approach. They come in different shapes and forms and you have to constantly remind your self that these people are not loonies. They passionately defend their point of view and argue their case with zeal and fervor.

One of the points of contention surrounding the #NoEstimates approach is the claim that there isn’t any difference between estimates and guesses, so much so that the two are synonymous. The offshoot of this idea is that it is better to make decisions without estimates as estimates are just guesses, and making decisions based on guesses is a futile idea. You may as well make a decision and adjust it as new information comes to hand.

For some peculiar reason the support for this notion seems to be coming from those exercising Agile. The rebellion against the ‘old bad ways’ is taking on a new momentum, beyond those chartered in the Agile Manifesto, and is now expanding into new territories. At the center of this crusade lies the notion of uncertainty and how it should be dealt with. As uncertainty is..well, uncertain, what is the point at attempting to fence it with unsubstantiated estimates. Surely they will never be 100% accurate, so why try?

Although, IMHO, this way of thinking is fundamentally flawed it does, nevertheless, have a silver lining that should not be dismissed. It represent a new generation that questions the validity of established practices and wants to explore other, yet to be chartered, ways. That, in itself, is a good thing. Whether the conclusions they arrive at are correct, that’s yet to be seen, but it is great to have the discussion.

Think about it!

The Agile Manifesto states that:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Please review the above (take your time) and then answer the following questions:

1. Does the Manifesto suggest that agile teams cannot be externally managed?

2. Does  the Manifesto suggest that no documentation will be produced?

3. Does the Manifesto suggest that an Agile project should NOT have a plan?

4. Does the Manifesto suggest that work should commence without having a clear end objective in mind?

5. Does the Manifesto suggest that the customer should commit their money without knowing what would sensibly be delivered to them at the end?

6. Does the Manifesto suggest that development estimates need to be made in points and not be committed in hours, days, weeks or months?

7. Does the Manifesto suggest that the only fixed variable is the budget and that everything else is up in the air?

Think about it!

The notion that Agile removes the need for proper planning and proper scope determination is just that, a notion.

In the real world, and in real projects, the mere thought that a serious development would get a business blessing to spend real money without knowing what they will get for their money is, yet again, just a thought – a baseless concept.

Projects are about benefits realization and the way benefits are realized is via the delivery of capabilities that are the outputs of the projects. The idea that capabilities could be just work in progress, progressively being added during a progression of iterations or sprints, without having a clear visualization of what they will all add up to at the end is pure nonsensical and no serious organization will be willing to commit its scarce resources on such an expedition.

So when someone tells you this is how Agile does it don’t take their word for it.

Think about it!

I was invited to a meeting in one of the building in Melbourne’s CBD and have spotted the following in the building just across the road.

What do you think is happening up there? Click on the image to see enlarged version.

Think about it!

The following video is a result of a conversation that took place at the PM UK APM Knowledge SIG in November 2012.

Do BOK’s, in their various guises and incarnations, add or stifle wisdom and creativity? Watch this video and decide for yourself.

Check out also the related discussion in Linkedin – fascinating!

Think about it!

Many thanks to Jon Whitty for bringing this to my attention.

In recent months I have been part-time engaged in the documentation of a practical Earned Value Management System (EVMS) guide. The purpose of the guide was to integrate the ANSI/EIA-748-B-2007 with my company’s processes and procedures and align the terminology so it is easier for project managers to use the EVM method as part of their project practices.

As I was working on and writing up the guide I have met and had discussions with quite a number of project managers, both from within and outside of my company. A common theme that I have come across was around the concern that the collection of the base data and the maintenance of the metrics system arising from EVM is too complicated and will create unnecessary overheads on project managers that are under pressure already. It was clear to me, as a result of these encounters, that EVM is not well understood and that the cost / benefit aspects of utilizing it are not properly grasped by a large number of PMs.

One of the other aspects of these discussions that struck me as odd was the realization that the above perceptions were equally shared amongst PMP certified PMs. Why odd? Because I thought that the fact that the PMP certification requires basic knowledge in utilizing the EVM metrics for project monitoring and control will provide PMP holders with the basic understanding and the mindfulness required to integrate EVM into their projects.

This is clearly not the case, and here’s why:

Unlike the PMI’s Practice Standard for Earned Value Management, the PMBoK does an injustice to the domain knowledge of Earned Value Management in that it focuses on the way the various metrics are derived and calculated but it allocates no space to explaining what key criteria are required to ensure that a sustainable and credible Earned Value Management System is put in place to allow for these metrics to be derived in the first place.

A PMP aspirant will be aware of (and indeed be quizzed on) the meaning and composition of the various EVM terms but will have no (PMBoK induced) understanding of the system that needs to be put in place to get the fundamentals correct in the first to begin with.

This methodological gap needs to be bridged and the complete (or at the very least – a subset) of the ANSI/EIA-748-B-2007 criteria for the establishment of a EVM System need to be integrated into the main body of knowledge and not just the EVM practice standard. This will ensure that PMP certified project managers are well versed with the EVM terminology and are able to better integrate these principles into their projects.

Think about it!

One of the least understood aspects of the Earned Value Management methodology is that unlike Balance Sheets and Profit and Loss Statements, numbers calculated using this method are estimates only and are only meant to be used as a tool for eliciting management action.

What does it mean?

This means that it is not just the results of various calculations that should be the focus of your attention but rather what they mean and what action you should take to have them ‘fixed’.

It is the proper implementation of the EVMS criteria outlined in the ANSI/EIA-748-B-2007 that would guarantee that the performance measures you will derive are as accurate as possible and thus increase the statistical probability that the forecasts and estimates derived are credible and realistic.

Think about it!

One of the reasons I love project management is that it encompasses not just procedural tools and techniques but also the ability to conceptualize other dimensions that – although are not strictly speaking necessary to guarantee good project management – are nevertheless fascinating in their ability to enrich and enhance the project management experience with a greater appreciation of the world around us.

It is in this context that I reviewed John Goodpasture’s new book, titled “Maximizing Project Value“. John is the owner of the “Musings on Project Management” and is one of the writers and thinkers out there whose opinion and thoughts, I believe, do matter.

The book is not a stock standard project management book. It does not tell you, not does it claim to advice on how to manage projects. So, if you are looking for a ‘how-to’ guide to project manager don’t bother. The focus of the book is project value. And, while you have your own thoughts about what ‘value’ really means in the context of project management, you are likely to have a different, or at least modified, view after you’ve finished reading this book.

There are at least two main different types of ‘Values’ you will become familiar with. One is Project Value and the other is Business Value.

Project Value is the worth of the project’s throughput, of the difference in business value measured before and after the project, as earned during the course of the project schedule.

Business Value is the worth of the of a project’s throughput applied to business needs, as measured over some business period.

Maximizing project value is really about optimizing and managing the tension between the project manager’s mission to manage for project value and the project sponsor’s charge to enhance business value.

The book is a journey through the various facets that ‘value’ has (with its different meanings and interpretations) as it makes its way through the inception of a project, where it flows from being a business goal, through strategy and into projects. It then gets elaborated in a business case and is being worked on by teams whose job is to turn it from a concept into a valuable reality through the identification of requirements and the realization of the project deliverables via the control methods known as earned value.

One of the many interesting aspects of this book can be found in the discussion around the concept of the project balance sheet.

The project balance sheet is a tool for managing value-at-risk between the business and the project. Its namesake is the accounting balance sheet. And just like the accounting balance sheet, the project balance sheet totals the interests of multiple parties who all have a stake in the project.

While a ‘normal’ balance sheet comprised of Assets vs. Liabilities and Equity, the project balance sheet is a balance between the sponsor’s needs and wants and the project’s capacity and capability to deliver against these wants and needs. The introduction of risk into this model complicates this simple scenario and the book discusses this impact at length.

While for most project managers the job is done once the project has been handed over to the business, the ‘value’ journey is not yet over as

the business has not yet benefited fro any of the business value of the project. In other words, the project’s business value is only potential; that potential is unlocked when the deliverables are put into operation.

The author refers to this phase as the ‘post-project value attainment’. This requires elaborate change management and specific risk management to ensure the value produced by the project can be realized.

John is a real fan of Game Theory (check out his blog) and the last chapter in his book deals specifically with the concept of optimizing payoff with game theory. You don’t have to read this chapter to realize the benefits of having the book but if you are into the intellectual challenge of such discussions you will find this chapter entertaining and informative.

Broaden your horizons and have a go at it.

Think about it!

2012 was the year of the marvellous London 2012 Olympics. But there was something else significant which happened during last year – the one millionth PRINCE2 examination was sat – see infographic.

For those of you who are not familiar with PRINCE2, it’s the project management framework which was used to successfully deliver all of the London 2012 Olympic projects. It’s also the framework which has been adopted by the United Nations to manage all of its development projects.

So why does this matter to you? Well, I am assuming that you have an active interest in project management if you are reading this blog. If you are a project manager then you need the best tools in your toolset to help you manage what are increasingly challenging projects, right? I think PRINCE2 is one such tool because it is based upon established project management best practices.

So what’s the difference with the Project Management Institute’s Project Management Body of Knowledge (PMBoK) (which if you hold the PMP qualification you will already be familiar with)? Well, PRINCE2 is process-based and is very good at describing what should be done, by whom and when. It describes the responsibilities of all members of the project management team, whereas the PMBoK tends to focus only at the project manager level (and to a certain extent the sponsor).

The PMBoK is very good at describing techniques which project managers need to know, for example the critical path technique. PRINCE2 is sketchy on describing techniques, although it does describe two – far fewer than the PMBoK.

If you have read the PMBoK from cover to cover you might be left asking the question “what should I do first?” or “what should I do next?” PRINCE2 answers these questions very well, but is not so good at describing how you should change a plan, if you’re running late for example.

Just as a joiner shouldn’t dream of going to work without both a saw and a screwdriver in their tool bag so a project manager shouldn’t dream of planning any project without a good knowledge of the PMBoK and of PRINCE2.

Which brings me back to the latest statistics for PRINCE2. More people sat PRINCE2 exams last year than any previous year –according to figures released by APMG-International, the PRINCE2 accreditation body. There were more than 144,000 PRINCE2 exams taken in 2012, more than 90,000 of these at the entry level Foundation exam and more than 50,000 at the higher level Practitioner level.

The demand for PRINCE2 in Australia also grew last year with more than 11,000 exams being taken, a 7% increase on the previous year. Australia now represents the 3rd largest market for PRINCE2 exams, after the UK and the Netherlands and on current trends is likely to become the 2nd largest in the next 2 years.

So, if this article hasn’t convinced you of the need for you to take your PRINCE2 exams, then perhaps the success of the London 2012 Olympic projects will convince you instead.

Author’s Bio: Simon Buehring is the founder and Managing Director of Knowledge Train which is an accredited PRINCE2 training provider based in the UK.