quantmleap

Dr. Alex Hope has an interesting article titled “Project Management as if the World Matters…” where he reaches a number of conclusions that I find questionable.

The gist of the post is summarized upfront in the quote below:

[argue that]…most project managers are not yet integrating sustainability principles into project management practice, and that the profession needs to evolve to incorporate wider social, environmental and economic impacts. In fact I believe that we need to facilitate an evolutionary leap in the way in which we define, manage and communicate projects.

Alex uses a comparison of characteristics between project management and sustainable development and concludes that:

The definitions of a project and project management seem to be at odds with the definitions of sustainable development that aim to recognize the long-term nature of environmental or societal impacts arising from business activities.

While the post is well articulated I believe its core premises are wrong and I will attempt to explain why:

Project management is about meeting objectives and produce outputs. These outputs, depending on the circumstances in which they are produces, could be seen by society as contributing positively or negatively to its well being. For instance, a project that results in the erection of an energy producing wind turbine could  be embraced enthusiastically by green power advocates and rejected vehemently by bird and wild life advocates. The project itself, unless instructed to do so by its sponsors and owners, would not be interested in the opinions of either one of these groups, as its objective is not to meet their objectives but rather to meet the objectives set out for it as part of its charter and business case.

This leads to the following conclusion: If sustainability was to be a concern,  this concern would need to be the concern of those initiating  the project, the business or customer whose money is  invested in this initiative. Should they not be concerned about sustainability considerations, and provided that the project is operating within the legal and regulatory constraints relevant to its location, then not only does the project not need to concern itself with these issues, it should  not be addressing these matters because doing so will be an unethical thing to do in its own right.

There is another point worth mentioning here, this time about the apparent contradiction between the characteristics of project management and those of sustainable delivery. Let’s examine one example:

A project is characterized as being ‘short term oriented’ while a sustainable delivery is characterized as being ‘long term oriented’. IMHO, this fact can’t suggest any conclusion regarding this question. A short term project can be part of a large program or work, designated to take place over a number of years, with expected benefits, that once realized, contribute substantially and positively to sustainability objectives. There is nothing inherently suggestive in the fact that projects are short term to imply that they are sustainability unfriendly. They may or may not contribute to greater sustainability but, as outlined above, not due to their own innate characteristic but due to the terms and conditions imposed on them by those setting the business and policy direction for their implementation.

Want to achieve greater sustainability… deal with the people not the tools and methodologies they use.

Think about it!

The discussion around the #NoEstimates drive has raised all sorts of axillary arguments. One of these arguments is that there is virtually no difference between an Estimate and a Guess.

So just to set the record straight:

An estimate is a quantitative approximation based on previously observed data. The more relevant the data is, the higher will be the expectation that the approximation will be close to the true outcome (and the lower would be the uncertainty associated with this approximation).

A guesstimate is a quantitative approximation NOT based on previously observed data – and is rather based on gut-feel and a guess. Naturally this will attract a higher level of uncertainty.

You can argue that estimates are imperfect, are proven to be always wrong, etc, etc. At the end of the day though they are not guesses.

Think about it!

Came across the following tweet courtesy of Sue O’Connor

“@jeffweiner: Vintage social networking twitter.com/jeffweiner/sta…” Love it!

— sue o’connor (@Sue_OConnor) June 7, 2013

Ok, I know this is not related to project management (or anything else I’ve ranted about lately) but this is important. Google Reader is closing shop at the end of June 2013 and this has caused me a lot o grief as I use it daily to source and collect interesting reading material. Having explored a variety of other options I believe I now found the best substitute. It is called The Old Reader and once you import all your subscriptions from Google Reader you will (if you are like me) feel at home fairly quickly.

Give it a go.

There are many discussions out there evaluating the merits of having a PMP (or other) certifications.

The following post,  titled “Should you get your project management professional (PMP) certification?” was brought to my attention and it provides a number of compelling reasons for an affirmative response:

1. A PMP certification makes your resume more attractive
2. PMP certified professionals earn higher salaries
3. PMP certification helps you learn a common language
4. A PMP can help you cash in on demand for project managers.

Do these reasons resonate with you?

Think about it!

The LiquidPlanner Blog has published the below Infographic which I am happy to share:

Thanks to Jussi Mononen I was introduced to the concept of Beyond Budgeting and found the following on YouTube. If you’r happy to entertain the idea that there are other ways – beyond the commonly accepted ones – to do things, then watch this video and see if it gets your wheels going.

I would love to hear what you think about it!

The word ‘Conspire’ according to Google can mean:

1. Make secret plans jointly to commit an unlawful or harmful act.
2. (of events or circumstances) Seem to be working together to bring about a particular result, typically to someone’s detriment.

It is not surprising then that when I was referred to a MindJet blog called Conspire, I approached the post with some care.

The post I was reviewing was titled “Hint, Hint: Project Management’s Dirty Little Secret” and some key gems are quoted verbatim below:

…project management still has one dirty little secret left: those deadlines you’re so worried about? They don’t really matter after all…

and, quoting from a statement made by a developer through the Harvard Business Review:

Everybody knows the schedule is a joke, and we pay no attention to it. It will be done when it’s done.

and finally:

Tasks rarely get done on time, anyway. If you’re already allowing extensions, you’ve already planned for this inevitability, so embrace it.

The notion that a project is a flexible endeavor where everything is up for grabs, that money is unlimited and schedule is only a recommendation, is simply wrong. I always challenge people who dare following this approach to put their money where their mouth is and honestly consider whether they would have been happy to commit their own hard-earned money on such a fishing expedition. The perception that due to uncertainty all responsibility is out the door is dead wrong, not to say immature and unprofessional.

Would you engage someone with such ideas as your preferred project manager?

Think about it!

I’ve attended a Meetup meeting in Melbourne last night which I found interesting. The purpose / objective of the meeting was described as follows:

Many Agile projects use velocity, burndown and burnup charts to measure the progress of the project. While these metrics measure the speed of delivery, they do not measure the business value it generates and this is where Earned Business Value (EBV) reporting is useful. Since the focus of Agile projects is on business value rather that conformance to requirements, the EBV reporting fits well within Agile projects and also sits squarely where the views of the customer, project manager and delivery team meet.

The essence of the EBV proposition was described as follows: While effort estimates for Stories are defined in relative terms (where as, for instance, a 5 points story is perceived to require five times more effort than a 1 point story); can a similar approach be used to ascribe Business Value to each story? This would mean that a business person, the Product Owner for example, would determine relative business value for each of the backlog stories (or features) and by doing so will enable a number of outcomes:

1. Assign relative priority to the order in which the stories need to developed (high priority BV stories over low priority BV stories)
2. Allow for constant scrutiny regarding the benefits of attending to the remaining stories that are of low value, versus allocating development resources to other projects where high priority stories might still be outstanding.

While this approach still needs some further elaboration it seems like something that would be worth while investigating and collaborating about. For instance, one of the questions I couldn’t quite put my head around is in relation to how would business value (being a relative and subjective assessment) be compared across different projects, especially when the people ascribing the business value are different people.

So, still work in progress but certainly worth thinking about it!

Over the past few weeks I’ve been trying to put my head around the #NoEstimates approach. I am not a cynical type of person and I have approached this investigation with open mind and with a view to rationally verifying whether the approach is sufficiently solid to be used in the type of corporate software development domains in which I normally operate.

For an approach, any approach, to be accepted by the mainstream it needs to provide a complete solution. To be taken seriously it needs to address not just an immediate problem but also all connected facets that this problem is associated with. When it comes to the area of estimates – in the software development domain – any proposed alternative needs to address the same type of questions and expectations that the current approach is attempting to deal with.

I have come across two main active proponents for this approach (Woody Zuill and Neil Killick) so I decided to do a sweeping review of their published writing to try and  gauge the completeness and comprehensiveness of their approach.

Both gentlemen agree that at the heart of the drive to obtain or deliver estimates is the need to make decisions. The types of decisions can vary but, most often than not, they will touch on such issues of affordability, about investment strategies, about ROI, etc.

They also agree that while the need to make decisions is a legitimate one, estimates are the wrong tool to enable that process. They therefore suggest that as long as decisions can be made without estimates then estimates can be disposed of as an unnecessary, redundant and useless technique.

This is how Woody sums this up HERE:

…it looks to me that what we need are decisions, not estimates. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can,  and maybe we should explore other ways to make those same decisions.

At the heart of the proposed approach lies the following proposition (see in Neil’s post HERE):

Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint). Within that constraint the team can then fix incremental delivery dates (e.g. end of every Sprint) to allow focused effort on iterative product evolution (it’s not good to have priorities changing every day on a whim) and provide the opportunity to deliver early and/or under budget. This approach is also useful where there is no concrete budget or delivery date, although the need for interim release dates diminishes if the team (and organisation) is mature enough to have a continuous delivery model.

And a few additional comments from Woody’s blog:

Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here...]

Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along.  That is an important point. Dwell on it.

To summarize, given that estimation has ‘built-in’ uncertainty associated with it, this uncertainty can be completely removed by fixing a delivery schedule based on a per-agreed budget and/or time constraint.

So this is my understanding of how this process is proposed to work.

1. The organization allocates fixed amount of $’s and uses these $’s to ‘buy/hire/employ’ a certain number of resources (I am assuming that these resources could be people and assets, as appropriate)
2. The resources are allocated to work on development activities, with the priority being determined by the business value these will deliver.
3. This is progressing in an iterative manner until such time that the allocated funds are exhausted or until such time that a certain milestone, or predetermined date, has been reached – at which case the process ends.

If I was an owner of an organization and someone were to approach me with the above proposition I could decide to take it on. Given the fact that I spend my own money I can certainly decide that this could work for me.

What if I were to spend someone else’s money? Would that change the dynamic of that decision? Let’s explore this question:

When committing other people’s money there is often a requirement for transparency in the decision making process. In this case the following are legitimate questions that person can ask:

1. “why did you decide to spend my money on this product, and what will I get for my money at the end”
2. “I have a number of products I can invest my money on, why should I spend my money on this product at the expense of other products?”

Woody is suggesting the following to mitigate these questions:

There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.

This, on the surface, is not a bad advice but does this approach work for large and complex implementations?

Would you commit many $50M on an enterprise ERP configuration project with the approach that “we will make decisions as we go”? And even on a much smaller scale. You need to make an investment of $2-3M on a new Document Management System using SharePoint. Would you make decisions on the fly given that you need to commit upfront funds  for purchasing the software and the hardware on which it will ultimately reside? Sure, determining what will be developed and allocated to each and every iteration can be done progressively throughout the project, but what about the large and more strategic decision?

While some aspects of the #NoEstimates approach can work, they can only work in very limited and confined circumstances. I suspect that even then they cannot be implemented on large scale software development projects, and they cannot be implemented in organizations where strategic budget allocation is done based on cost benefit and ROI considerations. Until such time that this approach can demonstrate how it would deal with these issues, from my perspective it is busted.

Think about it!