How much will it cost?

The first thing they want is the estimate: How long will it take? How much will it cost?  These are not easy questions to answer- especially when no one knows exactly what the customers want to build. How can we give you an estimate when you don't know what you want?

We are on a project where they hired someone to figure it all out first. The analysis team spent a year, with numbers around one hundred people, learning about the customer, researching technologies, and spewing out documents- in the thousands of pages.  Then they came up with a schedule for someone else (eventually including us) to start delivering systems incrementally- and called it Agile (with a capital A): fixed-scope, fixed-schedule Scrum.

Unsurprisingly, it didn't work.  The analysis team missed half of the requirements for the most important application.  Their technology selection process came up with numerous wrong answers. The first few incremental reviews were perceived as having come from a year of work. A battle began between the implementation and analysis contracts.  It got ugly.

So they started over from a contracting perspective. Good-bye to fixed scope. Good-bye to fixed schedule.  A new dawn for "real Agile"?  Except that now the customer wanted a schedule- they wanted a price and a schedule for scope- scope that was not at all agreed upon.

We had a modest proposal- if you want a fixed cost, fixed scope contract, make it short. Make it a month or a quarter.  Give the customer the option to cancel at any time. Use rolling wave planning.  Of course, the customer budgets work years in advance, and uncommitted funds often disappear.  So you have to write a contract that specifies these iterative and incremental development cycles for about the size of the team the customer can support.  Use a little bit of data to at least put you in the wide part of the cone of uncertainty. Refine the estimates with each increment based on real evidence.

Stay tuned to see how it goes.

Are you creating value?

In the Lean view of the world, the theory of business that emanates from the Toyota Production System, the focus is on delivering a continuous flow of value and avoiding waste. Our business is formed around delivering value to customers. When our team arrives on the scene at a project- often a project that is in trouble for one reason or another, the first thing we look for is the customer. In order to provide value to the customer, one must understand what the customer values.

How do we understand what the customer values? The values must be communicated to us- but, still how, and by whom or what? Too often, we show up on a project and there is a huge document that purports to represent the customer's needs. In some cases, we are told to look at the existing systems they have and recreate them, with changes. In other cases, we are told that some other project functionaries will be spending their time visiting with the customer, and the the people designing and building the system will not be dealing with the customer. What does the lean approach tell us to do?

The Toyota Way recommends a simple thing- "Go and see for yourself to thoroughly undertand the situation." Also known as going to gemba (Japanese for "real place") or genchi genbutsu (Japanese for "real thing"), this allows you to make accurate decisions based on real observations. Rather than acting based on reports or hearsay, we should strive to create real human interactions with the people involved in the mission and understand what they are trying to accomplish. This will help put the technology in the right place.

Your job, your primary goal, is to help accomplish the mission of your customers. If you do not deeply understand this mission, you can only act in a shallow fashion. You will only be providing tools, and you will not be aware of whether or not you are providing value.

What is this about?

We work on a lot of projects. We see a lot of opportunities for improvement (aka problems). We provide a lot of solutions.

There are patterns to the kinds of things that go wrong on these projects. There are root causes that need to be addressed. There are things that we know really work, and we're trying our best to make them happen.

That process would be far simpler if people already understood what we are trying to do. Therefore, we are kicking off this effort to attempt to work out the specifics of the process and communicate it in an effective manner to the necessary individuals such that everyone's chances for success are improved.