Building the Unneded and Unwanted

Have you ever had that moment in a demo when the business champion of the project asks, “Why is that there?”  or maybe “Why did we do that?”.  As the supposedly omniscient project manager you suavely reply because we had a requirement to do that.   “Are you sure, lets check in Jira”.  Where it may or may not actually exist.  If it does there is another “Why” question.  Eventually, it always turns into “I’ll look into that and get back to you”.  The rest of the story is never very pretty.   I plead guilty to having this happen on my projects on a number (let’s not discuss exactly what that number is) of times.  Predictably the “looking into it” dead ends at one of these discussion points with the BA, the developer, and sometimes yourself.

  • That’s the way we have always done this
  • I thought you told me you wanted this
  • You told me to do it this way
  • She (or he) said that we should do it this way.
  • There is not other way to do this (yes there is)
  • Everybody does it this way
  • Our competitors do it this way

No matter what the reason, building the unneeded and unwanted wastes resources in the form of time, money and manpower.  We will return to this later to discuss strategies to prevent this from happening.

Not Building the Not Needed

Not Built-The Asked for But Not Needed

For the ethical and experienced project manager, analyst or developer this is a troubling area.  Most project manager job descriptions include the phrase business acumen.  The returns over 6500 hits for Business Acumen, the first one is in skill development.

The complement of leadership, business acumen and technical project management skills essential to employers of project talent. The knowledge and abilities necessary to manage scope, time, budget, stakeholders, teams, communications, risk and other project components.

Dealing with this kind of issue takes some business acumen to successfully resove.  After all, what is project manager to do when time and budget are in a crunch and you have a list of “Asked Fors” , something that you know are not really needs?  For me the answer is to review the project priorities with the project sponsor.  Where do these items fit in relative to everything on the project plan that isn’t done yet and are positively needs.  Can these requests be moved out of the MVP first delivery (and maybe out of the second then out of the third)?  Of course, there is always the possibility that the what the project manager thinks is a just a want, may with more knowledge turn out to be something that really is a need. The important thing is that the discussion take place between the business and the delivery team.

Not Built-The Requested Needful

I don’t think there has ever been a project where there were not things that were both asked for and needed but still not delivered. This is often the area of intelligent tradeoffs and where most where the next project often gets born. Often features don’t get built because the team runs out of time and money. Sometimes the technology doesn’t exist and despite the need and the desire some portion of the needed scope just doesn’t happen. That does not mean it won’t happen in the future, just not part of this project. The challenge of course is knowing what is really needed AND what can realistically be built within time and budget constraints. Allocating resources to things that are needed, but just cannot be delivered is not a good practice and can turn a good project in to a bad one. The key here is really stakeholder management and care presentation of facts, not alt-facts, real ones. It can be really hard explaining to a key stakeholder that some badly needed feature will likely break the budget and blow the schedule, but it is often the right path. I recently did an ROI presentation on a wanted and needed feature that instantly convinced the project sponsor to drop significant scope from the project which also allowed us eliminate a major schedule risk. A small loss of scope is much better than a great loss in schedule and budget. Often the lessons learned can be applied to the “next project”.

Building The Requested Wasteful

Building The Requested WastefulThe intersection of What Technology Built and What the Business Asked for that is not was the Business Really needs (Sometimes known as wasteful of the first kind) is a troubling area.  Many times we technologists and project managers build exactly what our client wants, but it turns out to be something they don’t need at all.  This can be functionality or features that the business perhaps spent days or even years, pining for. Now that they have it is clearly not needed.  Sometimes it is an executive’s pet project or a bright idea for a product.  Think of New Coke the Ford Edsel (  The accountability for minimizing this waste (it will never go away) lies with the Business Analyst, with the emphasis on Analyst.  Sometimes there are good strategic reasons for these flops and wasted resources because the organization learns important lessons.  Would the iPad have ever been invented if Apple had not built the Newton, and would it have been successfull without the lessons learned from the Newton?  Nobody knows the answer



Delivered: The not asked for needful

Perhaps the most misunderstood section is where “What Technology Built” intersects with “What the Business Really Needs”.  I have heard this section referred to as “Bliss” because we technologists have delivered good stuff that is more than what was asked.  At the same time there is a wide body of literature that calls this Gold Plating.  Most of the time this is neither but rather the results of poor or incomplete communication between technology and the business.  More often than not these not asked for things are what I call the “ities”

  • Availability
  • Security
  • Recoverability
  • Usability
  • Performance (ok it doesn’t end in ity, but it still counts)
  • Extensibility
  • Supportability

In one sense they are all delivered to some degree, asked for or not, but the level to which they are delivered varies widely.  In my experience the business will only ask for these after a bad experience of having not has sufficient delivery of one or more of them on a recent project.  At the same time adding killer functionality that was not asked for also falls into this area.

The obvious solution is to discuss the “ities” and the great ideas for new functionality with the business or client.  To some it might seem more like a class called Information Technology for Executives.  But it will be time well spent

Sweet Spot

The sweet spot of the diagram is the intersection of all three fundamentals.  This is where every project manager tires to steer the project.  Or maybe it is herding the project by pushing all three circles to the center.  In a perfect project all three would perfectly overlap and the diagram would be one dull green circle.   What a boring world that would be for a project manager.  However I’m not too worried about boredom from that happening, at least not any time soon.  Next we will do so some analysis of the areas that are not in the sweet spot, what they are, how the come about and what we can do to make them shrink or disappear.


Steering around the storms is the key to smooth project execution and smooth steering depends the business need, the business request and the technology delivery all be aligned.  Long when I was in grad school back in the 1980’s I first saw the tire swing cartoon (it has its own Wikipedia entry and dozens of versions posted)  I thought it amusing and as it turned out painfully prescient of what I found once I started my career.  Since that time there have been dozens or of methodologies and probably thousands of papers written that addressed some of the issues represented in the cartoon. In all of this there seems to be missing a root cause analysis and a lack of a fundamental model that explains what is happening.  A while back I saw a simple diagram, that when fully analyzed can tell us what is happening.  Which is the first step in making positive change.  To simplify it comes down to alignment, getting three fundamentals aligned:

  • What the business needs
  • What the business asks for
  • What technology delivers

More to come