How do we get people to commit to something when everyone has a different perspective based on role or even political leanings for larger companies” “Our stakeholders are petrified to commit to a final stake in the ground for fear they will not be able to modify it based on I.T.’s inflexibility and inability to change”

I though perhaps these were problems we had overcome in our industry, as the solutions are fairly well understood. I was wrong. What is the bottom line break-down between I.T. and the Business? That is a long and colorful debate. However I offer this:

• 
  
  Most organizations punish those who are bad at PREDICTING THE FUTURE in software engineering. Of course these are smart people but they continue to demand clairvoyance with a lack of statistics.


• 
  
  What happens? Padding of the schedule and bitter fights for every last month, when nobody has any idea what the effort is, not can they quantify the quality, and more importantly maintainability requirements around a software initiative.


• 
  
  The fact is you cannot know at a micro level about a project until you are well into building it. This is something I have never met a receptive audience for, however it proves itself time and time again.


• 
  
  “How do we give people the freedom to change their minds, yet deliver concrete estimates on time and cost to our managers?”


• 
  
  “How much will this cost us and how can we estimate it knowing we will likely change our minds during the project based on previous projects, and how can we get early and consistent involvement in the development process?”


• 
  
  “How can we ensure that necessary quality is met when we always enter risk mode at the end and quality goes out the window? Can’t we manage with quality at every single stage, even every day?!”

Whatever you do (in my opinion anyway) Don’t say Agile…Nobody on the business side cares. In fact for whatever reason, software causes perfectly rational people to loose their mind (I cannot really blame them).

What I have to say on the matter is accompanied by deep battle-scars. What I have to say is definitely not what most want to hear, and even the technologists want to argue that they CAN come close to prediction. However what I say has the ‘added moral quality of being true’. This is hard to argue in light of the facts. That still often changes nothing, as companies firmly plant their head in the sand again and hope for the best with no real way of knowing what will happen and no practical way of really tracking in real time how their exposure to risk is changing.

I know… I know… Agile is 100% about that but not in the way (typically) this group wants to hear, no that is why a knockout one-two punch is as follows (to be insanely overly simplistic):

1) Heavy Statistical Metrics for the ‘Planning’ View Inclined

2) Of course, Agile Practices to Provide the Inputs to (1) and to Optimize your Chances on the Execution Side

This article is about some detail around (1) that far too many miss in my opinion and why it doesn’t serve you to mix the terminology of these two groups (one of the only occurrences where I recommend that as I am typically the one pushing everyone into ‘one common Domain Driven language’)

The Four Critical Dimensions

When addressing the concerns of a new custom software project these are the four key elements that must always be addressed (there are others such as security, scalability, etc. but those are included in ‘Scope’ as functional and non-functional requirements):

• 
  
  Time (cannot be made)


• 
  
  Scope/Features (you cannot know it until your done, so now what?


• 
  
  Quality (not typically discussed, as who wants ‘bad or sort of low’ quality)


• 
  
  Cost (Since you have almost nothing to go on here, what to do? Your agile consultant says the system is ‘done when it is done, not when some arbitrary date is set’ and he is 100% correct. However the business gets to decide when it is ‘done enough’ not I.T. (with exceptions of course)

As Quality is not usually debated (I have never had a client say that the software could be poor quality), that leaves Time, Scope and Cost as the main moving parts to work with.

The diagram above is where many stop. That is missing the entire point, as the DRIVERS that facilitate your ability to do well are missing. For example:

1) A lack of a continuous integration environment with regression tests will severely hurt your ability to achieve quality (all things being equal)

2) A bad process / culture kills just about all of it

3) Bad team morale is the same coin, different side.

4) A process that cannot manage the inevitable change in scope as we ‘discover’ what the project is all about, will kill just about all of it.

5) A team lacking in solid design skills (design for change) such as a mastery of the important design patterns (Strategy Pattern Anyone?) as well as a lack of a Dependency Injection Container (there is just no good reason not to use one)

6) Lack of an Object to Relational Mapping Abstraction Layer. Deal Breaker as of today (perhaps not a year ago).

There is no real doubt by anyone (except for a few people who also are not so sure on the whole evolution thing) that Agile practices provide the common sense way to address the same concerns most of us have around software.

You know it, I know it, we all know it. However they don’t care (and really have likely heard some bad things about it).

My assumption is you are a person on the software side in a managerial capacity of some sort. I made this mistake for you many times. Resist the urge to ‘set them straight’ or to explain the wonders of Agile when asked these questions (or even when not) and instead… I’ll be getting to that….

Anyway, they would probably just think ‘how 2004’ and ask about SOA or something….

There are some real deal-breaker assumptions around project planning with or without Agile execution (and without agile is very well might be an execution.. OK enough biased injection for one article).

There is often an unspoken (and unrecognized) characteristic that you should be able to ‘tell the future’. And many will think that the worse you are at it, the more likely it is you just might be lazy and/or stupid. I’ve seen it over and over and over. Those who spin, those who pad, those who create fluff to buy time win. Those who really try and don’t play games get nailed to the wall.

Count me in the ‘dumb and lazy’ group because I am terrible at predicting the future.

In high school I was certain this really cute cheerleader would accept my invitation to the prom. I was also certain a few years ago that a system could be built for W dollars, in X months with Y people and Z quality. After all, that is all I could get from the customer as they were taking no input from vendors. Sure it was aggressive but we were so smart! We could do anything!

Both had similar endings.

“In order to succeed in complex software planning, just like in Agile, you have to give up. You have to completely accept the fact that you cannot possible know what you are really doing until you are already well into a solution, at least not at any detailed level”

Sound familiar? But you know you need these Agile ideas on the ‘other side’ and you also know it would be self-defeating to wave that flag..

Nobody wants to admit they lack power, especially in areas they have devoted their life to mastering. But why does this not only empower you, but create the bedrock of extreme competence and success? Is this like the alcoholic finally admitting he is powerless over the bottle? Only then can things get better? I doubt it. This is only software.

·

The Monetary Stakeholders

And for they people either funding and/or profiting from this exercise the concerns can be quite different.

“How can we ensure profitability on our work when we know change will occur? (For internal IT they may be managed and accountable for profitability if they are run like a profit center). If not profitability then “How can we possibly commit to a date and cost when we know this will be a moving target as we evolve the solution?”

“We have an abysmal record of missed deadlines, cost over-runs, quality problems and our users not being happy with our delivered systems. What can we do to improve this?”

“How do we manage the scope changes and ‘feature creep’ placed on us by the business people/stakeholders? This is what typically destroys our profits and/or time commitments and cost commitments, often resulting is a severe quality issues as well. How can we give people what they want but manage this change?”

This article is about bring these two groups together and keeping them just apart enough. This article is targeted to the people who must deliver software to their clients (be it internal IT or an outside Agile consulting firm doing the work). I assume these concepts would work in a non-Agile Process environment but I have cannot remember much luck (or for anyone I knew) in those days without resorting to what I call ‘white tricks’ so I will not comment.

A Framework for Project Statistical Success Optimization

We know that these two very distinct groups will need to work closely together in an Agile environment if we want to optimize our chances. The days of separating the business experts from IT is long gone. In fact, for an Agile project to succeed it is typical to actually have a business domain expert on the development team as a fully fledged member.

‘High Ceremony’ software processes may work (it is really dependent on who is doing the work as an amazing team will almost always succeed – see Peopleware by DeMarco and Lister) but at a large opportunity cost in almost all cases.

Any assigned domain expert should have the reach to get answers to questions quickly outside their domain knowledge when required. For a non-trivial project it will likely cover many domains and it may not be possible for that individual to have a mastery of all of them, however this person should be able to expeditiously get answers from others when required, This is a critical success factor to any Agile project.

I have evolved over many years this approach to software profitability and risk management in a very well tested and disciplined way. It has evolved since 1998 when I was CTO of a niche financial services software firm, which was sold in 2004. I then started the firm agilefactor and significantly evolved these ideas further as I still do literally almost every day! It’s 2007 and there are many war wounds.

If any of this content seems like ‘academia’ or ‘theory’ I can assure you these are all proven real-world strategies, having been applied by myself and many others for years and years.

At the most basic, one could say everything eventually comes down these four critical dimensions…

It is CRITICAL you never let a client box you in on all of the three of these items if it can be avoided or you may have to ‘walk away’ from a project (many in internal IT do not have that luxury but at least this article will show you how to push back in a way that is hard to be disputed by the forces trying to box you in to possible assured failure).

Your client gets to drive only two of the three items at most (such as Time and Cost), while you driven the third (Scope in this example) or the remaining items you control (you must always have at least one that the client explicitly gives you control over).

This is critical to profitable software sales both for commercial and custom one-off development but many fail in this area in their eagerness to close deals (this is especially a problem with salespeople who are not put in check on what they can promise the client, and will promise you right into a massive loss – a lesson I learned firsthand early in my career).

For example, if a client says:

· We are allowing vendors to work until October 1st to achieve these 120 individual scope items in the attached 600 page scope document we have assembled (the first major sign of trouble).

· Vendors have $1,900,000 to build this system. This is non-negotiable and the software must be extreme production quality, with severe contractual penalties for down-time, with scaling up to 10000 concurrent sessions per machine with an average response time of one second or less “

Do we walk away? My initial reaction is absolutely..

This violates the principle described above as you are not in control of any of the four critical elements. The answer is sometime you must walk away!

I will describe here a way to help determine if you should and how you can effectively push back on this, as we know there will be significant deltas on that scope document (both academically from studies and practically from our experience).

We really have no idea if we should accept these terms. There are ways however where we can at least assess the risk and possible accept the terms when we learn these tools.

We all know it is an agile imperative deliver a working build to your stakeholders for each iteration that is ‘real production’ although a subset most of the time

The client drives at most two dimensions, and you must drive the third (again ignoring the Quality variable) or you risk a disaster for everyone.

And after all, THEY are deviating from ‘the plan’ they committed to with confident assurances that there would be little to no need for ‘change orders’ (this is a common occurrence in my experience with a correlation to the larger the company the most convinced they are the scope will not change.

Establish Risk Tolerance Before Defining the Time, Scope and Cost Constraints

Based on the extensive research and project database built by the industry luminaries and incredibly esteemed experts Tom DeMarco and Tim Lister, we now know what the probability distribution curve is for new custom software projects. It is lognormal with a high peak and a long curve to the right. This is absolutely critical for everyone to understand and I highly recommend you read the book “Waltzing with Bears” for a detailed discussion (see the end of this chapter for more information).

This is the probability distribution curve we must embrace:

You establish the client’s willingness to accept the unavoidable possibility of failure across any of the four dimensions (we cannot predict the future) and then find that point on the curve moving up from the X axis point you have for the client (the X axis is probability of success) and take the area to the left of that point.

The total area under the curve is 100% so the farthest right point would indicate 100% confidence (again basically impossible to achieve where most organizations assume 100% by default, something that must change if our industry will ever ‘grow up’. As we cannot control the future, we can only manage it and the risks, we must know how ‘risky’ the client wants to be (again by asking them or inferring it ourselves – often manifested in a ‘public’ date and an ‘internal’ date which is past the public date if we know the client will not cancel the project or penalize us tangibly for missing the public date).

It is a typical ‘risk/reward’ situation. If the customer takes on more risk we might save them money, or deliver early. If they want less risk, we must significantly increase our cumulative resources attached to a project with the knowledge that ‘adding people to a late project makes it later’. This we know as fact so adding people is really only an option in the early phases. This has a large impact on early project planning.

· We need to understand if a customer is OK assuming a 15% risk of failure for example.

· After all, don’t all future events have unknown outcomes?

· Is the client willing to as much as double their budget for a say 10% increase to 95% probability of future success across all dimensions?

A 95% success promise is not only near reckless to offer, it is an incredible shifting of risk anyone should demand a rich reward for taking on.

Studies are behind me on this as well with the well established fact that the best developers are as much as 28 x more productive then the worst). It quite literally is often a 100% increase in total resources allocated for a project to move from 85% to 95% even though it is a 10% gain in probability, hence the very long tail. The highest I have ever had a client go is 90% and we actually had two teams in two locations for redundancy (they didn’t know about each other). One team almost failed but delivered a solution, however the other team’s solution was superior so that is what we went with. This gave us our high probability due to the redundancy and the client paid dearly for this safety.

For example, the development team may say:

“We had a terrible two weeks. Our lead Cryptography expert was sick so we moved those features into the next iteration and we severely underestimated the complexity of the mainframe integration and User Profile Customization.

Therefore we could only achieve 50% of what we had planned for this iteration. I would say from our agreed upon 85% confidence we are now closer to 75%. We can see if we make it up in the next iteration or we can take measures A, B and C to get back to 85%. What do you want to do?”

A better question I have for you is, would you rather not know this? Almost all organizations are nowhere near this level of integrated risk assessment, quantitative measurement and adjusting action execution.

This is typically a decision for a high level individual (typically the project manager with the optional input of the customer) and hopefully with input from as many people as possible covering all dimensions.

Adding people will typically hurt you, not help you. You should already have done the obvious things like have moved the team into a ‘war room’ setting (almost always a sure way to improve productivity) or many other solutions, so if you missed any do it now as these techniques are proven and it is much more painful to fail.

As for the client, they can also be blissfully unaware of how we manage the process of our internal development, but this well established process makes it incredibly hard to fail.

Here is an example with risk tolerance. Based on negotiations with the client they have agreed to a risk tolerance of 85% (a 15% risk of failure). Based on this, you can now estimate knowing your margin for error. The customer has scope requirements, and cost requirements but is fairly open to time.

You come back to the client and say:

“Based on an 85% confidence we feel we can deliver your scope at the cost you describe at some point between April 1 2006 and July 1 2006’”. The client may protest, saying (for the first time) they were hoping for a March 1 delivery. You confer with your colleagues and respond that this would be possible at a 70% Confidence (30% chance of failure). And so the negotiations follow…But at least now you have very concrete ‘dials to turn’ and it is hard for the customer to argue with the fact base supporting you.

I assert that custom software is a ‘wicked problem’ (to see a great definition of ‘wicked problem’ see http://www.cognexus.org/id42.htm or the text at the end of this article.

Conclusion

To help ensure a positive outcome for your client and for your development effort it is critical to consider first the Risk Tolerance of your client, and then negotiate the one dimension you typically have control over after the client informs you of the two (two from Time, Scope and Cost). In some cases you must walk away and this article should help you determine when that is the case.

For a much more detailed discussion of these topics and what this author considers critical:

“Waltzing with Bears”, Dorset House Publishing Company, Incorporated (March, 2003), ISBN: 0932633609

Supplemental Material: Wicked Problems

A wicked problem is one for which each attempt to create a solution changes the understanding of the problem. Wicked problems cannot be solved in a traditional linear fashion, because the problem definition evolves as new possible solutions are considered and/or implemented. The term was originally coined by Horst Rittel.

Wicked problems always occur in a social context — the wickedness of the problem reflects the diversity among the stakeholders in the problem.

Most projects in organizations — and virtually all technology-related projects these days — are about wicked problems. Indeed, it is the social complexity of these problems, not their technical complexity, that overwhelms most current problem solving and project management approaches. (See graphic of wicked problem solving process below.)

Some specific aspects of problem wickedness include:

1. You don’t understand the problem until you have developed a solution. Indeed, there is no definitive statement of “The Problem.” The problem is ill-structured, an evolving set of interlocking issues and constraints.

2. Wicked problems have no stopping rule. Since there is no definitive “The Problem”, there is also no definitive “The Solution.” The problem solving process ends when you run out of resources.

3. Solutions to wicked problems are not right or wrong, simply “better,” “worse,” “good enough,” or “not good enough.”

4. Every wicked problem is essentially unique and novel. There are so many factors and conditions, all embedded in a dynamic social context, that no two wicked problems are alike, and the solutions to them will always be custom designed and fitted.

5. Every solution to a wicked problem is a “one-shot operation,” every attempt has consequences. As Rittel says, “One cannot build a freeway to see how it works.” This is the “Catch 22″ about wicked problems: you can’t learn about the problem without trying solutions, but every solution you try is expensive and has lasting unintended consequences which are likely to spawn new wicked problems.

6. Wicked problems have no given alternative solutions. There may be no solutions, or there may be a host of potential solutions that are devised, and another host that are never even thought of.

(from Rittel and Webber, 1973)