Reading some of the conversations around the need to adopt a more exploratory and adaptive approach to estimation (aka #NoEstimates) made me realize that there is something deeper going on here beyond just objecting to the delivery of estimates on ideological grounds. While the arguments against estimation are grounded in seemingly rational and logical observations, they represent, at a deeper level an ideology and a way of thinking that warrants serious contemplation.

Being a member of a team, any team, carries with it some responsibilities. If you are a member of a national soccer team and you happen to bite one of your opponents, this activity reflects on you and is consequently impacting your team. This is why when we talk about the members’ function within the team and within the organization we often refer to it as their ‘role and responsibilities’. Having a responsibility is therefore a part and parcel of your role – one cannot exist without the other. The combination of a role and its responsibilities is a sign and measure of being accountable. In this context, accountability means having a skin in the game, being directly and personally involved in the success or failure of the organization.

Providing estimates for a prescribed activity is a method by which the organization utilizes one’s knowledge, experience and expertise in order to make an investment decision. When you make a claim that the decision maker will be better off proceeding without this estimate you very much proclaim that you wish to NOT have any tangible stakes in the decision to proceed. You wish to NOT be held, even partially, accountable or responsible to whatever transpires. If all goes well you are happy to bask in the glory of the success but should things go pear shape…well, not your fault!

Think about it!

Related Post

The #NoEstimates Movement Recently I have been involved in heated debates on Twitter (and also in comments to an earlier post) with proponents of the #NoEstimates approach. The...
The #NoEstimates Fallacy 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...
An Estimate is Not a Guess The discussion around the #NoEstimates drive has raised all sorts of axillary arguments. One of these arguments is that there is virtually no differen...
Figuring Out Your Project’s Landscape Using ... Introduction Despite our best endeavors in codifying many aspects of project management, a lot of what we do in project management is still 'situatio...

The Cynefin framework identifies five domains within which systems and environments can co-exist. In summary the five domains are:

  • The ‘Simple‘ Domain – characterized by clear cause-and-effect relationships, with well-defined rules of engagement that call for the use of best practice approaches.
  • The ‘Complicated’ domain – where the relationships between cause-and-effect are not straight forward but are discernible subject to some level of analysis or investigation with the application of expert knowledge.
  •  The ‘Complex‘ domain – where the relationship between cause-and-effect can only be perceived in retrospect
  • The ‘Chaos‘ domain – where uncertainty is abound and no discernible cause-and-effect relationship are known to exist.
  • Disorder‘ – when no clear realization exists regarding the state at which the situation is and where no clear action can be taken due to conflicting views and complete lack of leadership.

When tying the concept of software development estimation with the Cynefin framework one has to consider (or rather ‘sense’) in which domain the system and the environment are and, based on that assessment, tailor the estimation process to account to that situation. The situations most likely to be present at the outset of the estimation process are as follows: Cynefin combinations Some of the objections to carrying out estimates touch on the variability (or rather uncertainty) associated with the state of either the System or the Environment. The Cynefin Framework recognizes the difficulty associated with managing complex situations and suggests an approach to effectively get them managed. Tackling complexity requires resident knowledge about the system and its environment and, more importantly, requires adaptation and openness to learn about them. Experimentation management is the key to overcome the fear of tackling the unknown. Rather than adopting an attitude of ‘it cannot be done’ I would suggest that an attitude of ‘let’s put in a place a process of experimentation so we can tackle the unknown’ would better serve the needs of both those delivering the estimates and those requiring them for business decision-making. Think about it!                       aaa

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

Cynefin - 0Introduction

Despite our best endeavors in codifying many aspects of project management, a lot of what we do in project management is still ‘situational’ and ‘variable’. That is, in project management we need to react to various situations and these situations are a result of any number of variables, the impact of which cannot be fully predictable, understood or comprehended in advance (and occasionally not even while or after they occur).

In this post I want to elaborate on the applicability of a common framework that project managers can use in order to map various situations in their project landscapes. The framework I would use for this discussion is called Cynefin (pronounced cenevin).

Discussion

Cynefin, the details of which will be elaborated on below, provides a conceptual framework for making sense of the different landscapes faced within and by projects. In ‘faced within and by projects’ I mean to say that this framework can be used by the project manager to understand the various landscapes faced by the project (for example the stakeholders’ landscape, vs the development team landscape – and don’t worry if you can’t understand it now, all will be clear by the time you complete reading this post) or the landscape of the entire project, compared with other projects (for example, a web development project vs an R&D project).

The Cynefin framework recognizes that the situations and challenges we face can belong to one of four domains:

The ‘Simple’ (‘known’) domain

The ‘Simple’ domain is characterized by the following attributes:

  • There are known Cause and Effect relationships and these relationships are repeatable, perceivable, predictable and can be determined in advance
  • Challenges can be addressed using Best Practice approaches
  • Activities can be usually codified and documented into Standard Operating Procedures and Work Instructions
  • Best suited for Command and Control style of management

In the context of project management, projects that operate in this space would be ones where the domain of execution is known, regular, predictable and with very low risk. For example, a software house specializing in the delivery of basic small business web-sites, where these web-sites are subject to a regular delivery routine and are subject to similar terms and conditions.

The way to deal with ‘simple’ problems (i.e. the way to make decisions) is by applying the sequence of sense-categorize-respond. That is, you start by assessing (or analyzing) the facts of the situation, followed by categorizing them (i.e. determining what best practice is relevant to deal with the situation) and then implement and execute this practice.

The ‘Complicated’ (‘knowable’) domain

The ‘Complicated’ (‘knowable’) domain is characterized by the following attributes:

  • The links between Cause and Effect are less apparent and not self-evident; but are able to be uncovered
  • No clear ‘Best Practices’ but there are known ‘Good Practices’

In the context of project management, projects that operate in this space would be ones where the domain of execution can be determined by utilizing existing expertise and the project’s risk can be assessed and managed. Less than trivial software development projects (i.e. projects where the level of uncertainty is not insurmountable) would fall into this space.

The way to make decisions in the ‘complicated’ domain is by applying the sequence of sense-analyse-respond. That is, you determine what possible practices would be appropriate for dealing with the situation and then, having selected one (based, perhaps, on the availability of experts in that particular domain) you then implement and execute this practice.

The ‘Complex’ (‘Unknowable’) domain

The ‘Complex’ (‘unknowable’) domain is characterized by the following attributes:

  • The links between Cause and Effect are only clear in retrospect
  • No obvious ‘best practices’ or even ‘good practices’ but a possible practice can emerge as a result of controlled experimentation where quick learning can be achieved.

In the context of project management, projects that operate in this space would be ones with high level of uncertainty but where low-cost-of-failure experiments can be used to narrow down the uncertainty and suggest an acceptable path forward. The type of projects that fall into this space will be innovation or R&D projects.

The way to make decisions in the ‘complex’ domain is by applying the sequence of probe-sense-respond. That is, you start by probing (i.e. trialing out various options using experimentation), then identifying the methods that succeeded and can be used as future patterns of operations for the future.

The ‘Chaotic’ (‘Unknowable’) domain

The ‘Chaotic’ (‘unknowable’) domain is characterized by the following attributes:

  • The are no Cause and Effect relationships
  • No point in looking for the right answers (as no right answer exists)

In the context of project management, project that operate in this space would be ones with high levels of uncertainty through and through. This could include projects with lack of agreement on the project’s scope, business value, mode of execution in a technologically shifting environment.

The way to make decisions in the ‘chaotic’ domain is by applying the sequence of act-sense-respond. The first thing that needs to be done is to take some action (which may or may not work) in an attempt to stabilize the environment and reduce the chaotic nature of the project. One example for a possible action would be to simply stop the project but other options are certainly possible.

Some final notes

There is much more to the Cynefin framework than described above and you are encouraged to explore it further here.

Determining your position in the project’s organizational landscape is important not only because it can prompt you to take the appropriate corrective-actions but also because it could prevent you from applying the wrong solutions.

In the context of recent #NoEstimates discussions it seems to me that the application (or rather the suitability) of the #NoEstmates argument is really only applicable to the ‘Unknowable’ domains. There is no valid reason to suggest that within the ‘Known’ and ‘Knowable’ domains estimates could not be provided (as a matter of fact in the ‘Simple’ domain and with some expert advice in the ‘Complicated’ domain).

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

Introduction

The raging debate surrounding the #NoEstimates concept has left me with a sense of frustration one usually feels when coming across an unfinished business. While a number of individuals on both sides of the debate have attempted to address the key differences of opinion, the question still seems to be unresolved with each side sticking to their guns, unable to agree on a common ground or a framework of understanding in which all parties can feel vindicated. In this post I will attempt to outline the key arguments for and against #NoEstimates. When possible and if appropriate I will quote these arguments verbatim, sourcing them from a number of blogs where this topic has been discussed (sometimes indirectly) extensively. I will provide links to these quotes but do my utmost to ensure I do not take these quotes out of context.

The format I plan to adopt for this post is as follows. Each argument, in favor or against the #NoEstimates proposition, will be listed and a statement in support and against the proposition will be provided. whenever appropriate I will add further commentary where I will attempt to narrow  the gap and articulate the assumptions arising from each or both arguments.

As the end of this post I hope you will have a better appreciation of the arguments and you will gain the ability to articulate your own answer to the following questions:

  1. Are cost estimates required in order to manage software projects?
  2. Are cost estimates an effective tool for controlling costs?
  3. Do estimates stifle creativity and kill innovation?
  4. Do people need estimates? And if so, why?
  5. Is the very act of estimation results in the creation of uncertainty?
  6. Is estimation a practice still hanging over from the Waterfall era?
  7. Is No Estimation better than Bad Estimation?
  8. Is  Estimation really just a form of Guessing?
  9. Are estimates necessary for Governance? Is it reasonable to require estimates for the purpose of pacifying governance needs?
  10. Is there any point in providing estimates when it is known that many projects fail due to lack of credible estimates? And aren’t estimates a tool used to apportion blame afterwards anyway?
  11. Is costing a necessary tool for determining business value?
  12. Does the scope drive the budget or does the budget drive the cost?
  13. If estimates are required in order to support decisions, can decisions be made without estimates?

We have a lot to cover so let’s make a start!

Discussion

1. Making software development decisions based on estimates are counter intuitive

#NE – There is a tendency in software development to, counter intuitively, take a reverse approach to budgeting we would employ when we make purchasing decisions in our lives. Instead of deciding our budget based on how much we have available, or are willing to spend – as we would personally do – we decide it using an estimate from the supplier of how much they tell us the software that we want will cost. So, while we have a pretty good appreciation of how much much we have, want or willing to spend, we are unnecessarily engaged in a bidding process with the view to find the cheapest bidder in order to save money and squeeze as much as we can for our real budget. In such case, would we not gain a better outcome if we work iteratively and collaboratively with the supplier based on our budgetary and / or time constraints? (link).

#E – The claim that iterative and collaborative work can be used as a substitute for up-front estimation of cost is challenged by Mike Cottmeyer in “Should You Use Agile to Build Your Next Home?“. The gist of his argument is that most people when they are spending their own money, want to have some idea of what they are going to get when the time and money run out. They want some assurance that they’ll have enough of the product they have ordered to make the whole investment worthwhile. Suggesting an incremental delivery, while appealing in theory, is not necessarily a practical outcome as even a fully functional software, when lacking the greater context might be unusable (just like having a fully functional kitchen might not be usable unless the bedrooms and the other amenities have also been complete).

The other factor worth mentioning here is the behavioral aspect driven through our understanding of economic theories. The concepts of Scarcity, Opportunity Costs and Cost Benefit Analysis dictate that people, intuitively, would look to determine future value before they make an investment decision. This determination is done, among other methods, by comparing one perceived outcome against other alternatives, and selecting the one that maximizes the perceived value (or Return on Investment).

2. Estimates are seldom correct so why use them?

#NE – A casual search on Google will reveal that faulty or wrong estimation is seen as one of the leading reasons for projects’ failures. Proponents of  the #NoEstimates proposition raise the following arguments regarding the lack of credibility associated with the provision of estimates:

  • Estimates are often gamed, and for various reasons (link)
  • They are often based on zero to low knowledge (link)
  • They are often being plucked out of thin air (link)
  • Time and cost estimates are based on an up-front estimate of scope (i.e. a guess) and as such are guesses at best, leading to obvious dysfunctions like death-marches, low quality, etc. (link)
  • Asking teams to estimate how long their work will take has connotations that their output is being measured by an external party (management), creating an environment of fear and massaging figures to reflect what is desired rather than what i predicted (link)
  • We should’t be defining all our scope up-front, meaning we shouldn’t estimate all our scope up-front, meaning we shouldn’t be defining our delivery date based on our scope (link)
  • It seems like we keep failing at getting good at estimates, even though we are working hard at becoming better at doing so, then maybe we are expecting estimates to do something for us that just can’t be done. (link)
  • Estimates, quite often, are a result of a a wild guess, aimed at providing some numbers that seem plausible and will allow the decision makers to approve the start of a project with a clear conscience. That is, when things sour later on, they can always blame the developers for giving them inaccurate estimates. And the developers can always blame the ‘requirements people’ for giving them unclear, incorrect, or incomplete requirements. And the requirements people can always blame the stakeholders for providing bad direction about what was important. And so on. Regardless of who is part of this process, it is one big happy circle of blame that lets us all do the wrong thing and still keep our jobs… (link)
  • When estimating a date or cost you are creating uncertainty around those things, because you are guessing. You are saying “we’ll deliver somewhere between here and here”. However, if your delivery date and/or cost is set by a real constraint, as advocated by the #NoEstimates approach, you have created certainty around those things. (link)
  • And see also Jens Schauder’s ‘8 Reasons why Estimates are too low‘ and Glen Alleman’s specific response.

#E – The arguments against estimates can be classified into two categories; practical and behavioral.

Lets’ start with the practical considerations first:

‘Doing’ estimates right (though not necessarily correct) requires effort. While we are all accustomed to performing estimates in most facets of our lives (when we drive our car, rush to the station to catch the train, do our shopping at the supermarket, etc) there are instances or circumstances in which making the wrong estimate can have more severe consequences. If we try to cross the street and misjudge the distance and speed of an approaching car we could be involved in a fatal accident. If we misjudge the effort required to develop a software feature we could end up being responsible for a business loss that could affect our very livelihood.

When we make an estimate we always take a risk. When we buy one bottle of milk for our daily morning coffee we base our purchasing decision on past experience coupled with some probability assessment regarding the likelihood of past patterns breaking up in the future. While we don’t explicitly enunciate that level of uncertainty, we subconsciously are aware of it. We know, intuitively, that it is never 100% but are happy to concede that there is X% probability (perhaps 90%) that one bottle of milk would be sufficient to meet our needs for the next few days.  Had the probability been low, we would most likely buy two bottles.

While making decisions (based on estimates) come naturally to us when we cross the road, the reason why we are comfortable making these probability assessments is because we have learned to execute them based on past experience. From an early childhood our parents have taken our hand and instilled in us the need to accumulate experience and knowledge we could utilize at a later age, without giving it much thought. Statisticians and Economists would call this process Reference Class Forecasting (and see Kailash Awati’s elaboration on this topic in Improving Project Forecasts).

In the world of software development we are asked to exhibit the same assessment skills with the appreciation that our reference class might not be obvious up front – i.e we might be having a Reference Class Problem. In a nutshell, this problem “…arises when we want to assign a probability to a proposition (or sentence, or event) X, which may be classified in various ways, yet its probability can change depending on how it is classified ” (from The Reference Class Problem is Your Problem Too, in Kailash Awati’s The reference class problem and its implications for project management).

At the practical level, being dismissive of the validity of estimation could be an attempt at avoiding the need to establish a reference class. If you don’t have a reference class on which to base your estimates then (as often argued by Glen Alleman) build one, run a pilot project, execute an experimental iteration, ask others who’ve done something similar. Do something to reduce the uncertainty and increase the certainty. There should be no excuses for not trying to establish some level of reference class baseline and progressing based on that starting point.

And now to the behavioral considerations…

The notions of gaming the estimates, plucking figures out of thin air, perceiving estimates as a mean to establish a management control and associating estimates with future apportioning of blame are all symptoms of a dysfunctional organizations. The business dilemma we need to address is whether the elimination of estimates would turn the organization into a functional one or would that just be a way of dealing with the symptom while ignoring the real problem. A better proposition should be to suggest methods to change the organizational behavior such that these attitudes are transformed into more suitable ones. Implementing the practical practices established for the delivery of estimates can go someway towards ‘fixing’ the organization. If you are a strong and vocal proponent of #NoEstimates you could equally be in a position to strongly support calls for taking the necessary steps needed to change the organizational attitude such that developers would not feel under siege every time an estimate is required (and see also the discussion here re. dysfunctional organizations).

3. Estimation = Waterfall

#NE – Estimation is seemingly one of the few remaining immutable practices hanging over from the waterfall era (link). Waterfall and predictions are harmful (link).

#E – See Mike Cottmeyer in “Should You Use Agile to Build Your Next Home?“. Tying estimates with Waterfall is not a solid argument and it seems to appeal to those with emotional associations tied to the Agile vs Waterfall metaphorical divide.

4. Why do customers need estimates?

#NE – The main reason we do estimates is because people need to make decisions. This means that the key requirement is for people to be able to make decisions. It is true that estimates are often used to help us make decisions. But estimates are not the only way and for many of the decisions we need to make they are likely not the best way to go. One good way to make decisions is by adopting the “lean approach”, by learning from our mistakes and by frequently taking corrective action (link).

#E – There is no disagreement about the conjecture that estimates are required to make decisions. As highlighted earlier, whether or not we are engaged in formal and conscious estimation process – we are still estimating sub-consciously.  And we do it because this is how we intuitively engage in risk management. We are always on the look for signals of danger and for opportunities. And while we are engaged in this type of behavior in every facet of our lives, we should more inclined to exhibit such behavior when spending other people’s money. The type of decisions we need to be able to ethically make are about whether we ‘buy’ this software or ‘make’ it.  Do we invest the money in this product or in any one of a number of other opportunities.

The decision regarding the investment path to be taken cannot be solely based on the perceived business value, as while a number of development opportunities might present a value proposition, the value differentiation might not be so clear as to determining the one we ought to pick for further development. And this is where cost becomes a deciding factor. It is called cost-benefit-analysis and it is a sensible risk management strategy.

Some final notes

The discussion surrounding the #NoEstimates proposition is one we need to have. The issues highlighted here are not raised with the intention to keep people from exploring and challenging established assumptions but rather as a concern against applying judgement without considering the context and landscape within which these judgments ought to be made.

No doubt #NoEstimates could work in environments where such a proposition will be accepted by the stakeholders who’s money is put on the line.  While I have not yet had the opportunity to operate in such an environment does not mean that such environment does not exist. And this is exactly the point where context need to be injected into the discourse around this issue. It is about establishing known boundaries or parameters within which #NoEstimates can (and perhaps also ought to) work. Some mention areas of R&D as suitable for this and perhaps this is correct. Establish a budget you are willing to use for experimentation (based on your risk appetite) and let the team iterate until such time that you either run out of money, run out of risk appetite or hit the bull eye. Other areas could be small developments with low risk. The domain is known and the time taken to produce formal estimates is better get used on actual development. There is, however, a need to avoid broad categorizations that add little to no credibility to the argument and add a sense of religious ideology to a domain that requires no such similarities.

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

I’ve done a lot of reading lately trying to put my head around the arguments and counter arguments associated with the #NoEstimates idea. I now have a better understanding, and a bit more sympathy, to some of the key propositions raised by the proponents of this concept. I will elaborate on those in a separate post but during my research I’ve come across the below proposition in Glen Alleman’s blog. It is simple yet practical proposition for dealing with the need to offer an estimate. If you can’t answer any of the questions outlined below you could be in the wrong business.

You can get within 15% in 5 questions using a binary search for any software component:

(1) Can you do this in six months? Sure
(2) Can you do it in 2 weeks? No way
(3) Can you do it in 3 months? Likely
(4) Can you do it in 6 weeks? That’ll be tight.
(5) How about 8 weeks? Sure that’s possible.

How possible? OK< maybe an 80% confidence of 8 weeks.

Good, get started, up date me every week on your Estimate to Complete.

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

I’ve come across the above while reviewing #NoEstimates discussion threads on Twitter. It is a thread I follow regularly but, of late, one I did not actively get myself involved in.

On this occasion, though, I felt compelled to react. I was completely taken aback by the statement ‘it costs what it costs’ and was wondering whether this is a serious observation, which – if you look for the thread – it appeared to be one.

By the by I came across a new HBR post titled “Consultants Should All Get Real Jobs”. The gist of this article is that consultants, whose time is  spent on advising others what to do, should get their hands (and the rest of their body) dirty and get themselves involved in the real world so they can truly appreciate whether there is real value in their ‘expert’ advice.

The author, Scott Berkun, makes the following observation:

I challenge all consultants to spend some time — at least a year — back in a “real” job, working shoulder to shoulder with the same kinds of people who pay for their advice. So few authors and experts are willing to do this, because they’re afraid. They know it’s much harder to be accountable for a real team, in a real company, for a real project, than it is to critique and advise from the safety of the sidelines.

And here’s how this is relevant to our case:

It appears to me that many of those promoting or supporting concepts like ‘it costs what it costs’ have never applied this approach to their own money. They seem happy to experiment and play with other people’s money and are therefore blasé about basic issues of accountability, responsibility and adequate use of scarce resources.

And thus, in the spirit of Scott Berkun’s article, is it not time we ask all these people to demonstrate how they applied this very rule to their own business?

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

Having been involved in a good number of discussions in various LinkedIn groups and on Twitter has made me stop and think about the ROI of these discussions. The question I had to ask myself was: “Do all discussions merit my time investment”? and “What is the point of my involvement – or, in other words, what am  I trying to achieve”?

Clearly, the reason why I got involved is because I have a view-point on some matters and I want to make my view known. There is, however, a more important aspect to my involvement – I like to challenge people to explore and reveal the real motivation behind their view-point. I also like to put in question assumptions that some so readily make. I want to break, or at the very least shake, unsubstantiated dogmas.

Let’s examine a number of topics:

1. LinkedIn discussion: In a failed  project there is no one else to blame but the PM!!!

What caught me at surprise was the fact that many responses were comfortable at accepting this proposition as valid. Before you get involved in this discussion you need to ask yourself the following question: “Some (or in fact quite a few) people think that it is OK to categorically put the responsibility of any failure on the PM. Does it really matter that this is the case? Should I really care? What’s the point of arguing against this point?”.

So, here’s my view. It does matter. I (and you) should  really care and it is important to argue the case for the following reason: I am a practicing project manager (i.e. I actually do it not just talk about it) and when someone comes up with a proposition that could, in some circumstances, impact my own reputation, I may as well speak up now. How can it impact my own reputation? Simple: Should I ever be in a situation where the project I was working on was deemed to have failed I want the circumstances leading up to its failure to be evaluated rationally and fully before a judgement on responsibility is being made. I could be at fault but that option should not be taken as the one and only option.Those advocating sole PM responsibility for project failures live in an unreal world. In the real world a PM is one of many players whose time, involvement and dedication are required to see the project through. While the PM is in charge of enacting the processes required to ensure a successful delivery, the ingredients  used  within these processes are not always conducive for a guaranteed success.

Is it possible that the PM has contributed to the project’s failure – absolutely yes. Is it always just the PM who can be held accountable for such failures – absolutely No!

2. The #NoEstimates discussion on Twitter

A hot debate is now underway in Twitter around the notion of #NoEstimates. This movement makes a  number of claims which can be summarized as follows: a) there isn’t much of a difference between estimates and guesses, so much so that the two are synonymous; and b) 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.

This discussion requires a much more focused and conceptual attention than the one outlined above. If you follow the discussion threads on Twitter you could conclude that the discussions carry a level of fervor normally seen in deep ideological, philosophical of religious debates.

This discussion is worth having because it touches on current methods that are seen as fundamental to the way project budgeting is taking place. It is also worth having because the notion of challenging current approaches is a welcome one, one we should not shy away from but rather address with due consideration and consider as a viable proposition, provided that it delivers the goods. A discussed in this blog and in others (see Glen Alleman and Pat Richard) this is yet to be achieved. Despite extensive probing, those advocating the #NoEstimates approach are yet to come with convincing steps of how this could be done in practice and under what circumstances would it work.

3. LinkedIn discussion: What is the main reason that projects fail?

The topic of project failures and the reasons for that is a classic one. It is topical and sexy because if you can suggest why projects fail you are also likely to suggest how to avoid these nasty pitfalls and claim the subsequent fame. Two points are probably relevant here: 1) Most discussions about this topic are bordering on the trivial and mundane, lacking any real insight or useful and practical advice. Over regurgitation seems to be the flavorful of the day and thus lack any tangible usefulness.

The point of engaging in this type of discussions is that it is a golden opportunity to challenge the commonly accepted wisdom and tickle people’s intellect to try to seek a better answer. So, for instance, if someone comes, yet again, with the well rehearsed list of the contributing factors for project failure, share with them Kailash’s recent article where he challenges the common wisdom and suggests an alternative (and a  better explanation) to the factors leading up to a failed project.

So, in summary, to make your point of view known you must be involved. Involvement has a  number of dimensions. You can be involved to raise your social profile or you can be involved to try to make a difference. Either way, focusing on areas  of public discourse that shape public opinion and public perception are intellectually stimulating and, in a small incremental way, are also useful. They help other people see differing view points and it can certainly help you better understand and focus on your own views.

Think about it!

 

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

In a post published almost two years ago I made the point that

…the apparent increase in the level of Agile adoption in recent years seems to link perfectly with the next generational change as we witness the gradual increase of Generation Y in the workforce. Gen Yers are perfectly engineered to adopt Agile. The team centric feature of the Agile approach is perfect for a generation who grew up in a collaborative, social media driven environment. Quick and short development cycles fit perfectly into the generational need to achieve and achieve quickly.

I also made the prediction that

Agile adoption will increase and with it the challenge for organizations to ensure this adoption is done for the right reasons. I wouldn’t be surprised if as a result of the growing exposure some changes will be incrementally added to the ‘methodology’ as this approach is maturing and entering center stage.

Fast forward two years and it is now a good time to take stock and gaze into the future.

One of the most noticeable phenomena we can witness today is the proliferation of Agile – as a concept – in almost every facet of the organization. The term ‘business agility’ is increasingly used to refer to adaptation of business processes, procedures and practices with a focus on delivering and achieving business value.

Adopting the Agile mindset also means  that organizations are now looking at the way they manage change with a view to enable faster response and adaptation to market and other organizational changes and remove or sidestep any organizational impediments that stand in the way of such responses.

The above mindset is also manifested in two undercurrents that seem to be catching an increased level of momentum:

  1. Beyond Budgeting – a management model that enables people in the organization utilize their knowledge and experience and make decisions without the burden of excessive command and control mechanisms stifling their initiatives;
  2. #NoEstimates – a movement to reduce the reliance on estimation, based on the assessment that most estimates are wrong and thus add little to no value to the organization.

It is worth noting that the Economist Intelligence Unit published a study in 2009, titled “Organizational Agility: How business can survive and thrive in turbulent times”, where it concluded that:

Nearly 90% of executives surveyed by the Economist Intelligence Unit believe that organisational agility is critical for business success. One-half of all chief executive officers (CEOs) and chief information officers (CIOs) polled agree that rapid decision-making and execution are not only important, but essential to a company’s competitive standing. Agility may also be linked to profitable growth: research conducted at the Massachusetts Institute of Technology (MIT) suggests that agile firms grow revenue 37% faster and generate 30% higher profits than non-agile companies.

Interestingly, the report also suggests that along side the above observations

  1. most companies admit they are not flexible enough to compete successfully” and further claim that
  2. Internal barriers stall agile change efforts“.

The observations brought earlier in this post seem to suggest that the path to clearing up these two issues is now well underway. The forces that have pushed the Agile revolution through the software development domain are now marching forth with a view to make similar revolutionary changes on a much grander scale. While there would still be resistance across boardrooms and executive teams it would be fair to suggest (along the famous line coined in one of the Star Trek movies) that “Resistance is futile”. The question now is not “IF” this mindset will prevail but rather “WHEN” it will get hold. The challenge for friends and foes is in collaborating in order to ensure that whatever transitional activities are taking place from the old to the new are done in a manner that ensures consistency and adaptability – controlled evolution vs forced revolution.

The future may already be here – it might just take a bit longer to see it.

Think about it!

Thanks to Kailash Awati for listening to my rant and helping me see the light at the end of the tunnel

 

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

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!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

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!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...
%d bloggers like this: