6. A Risk and Issues List

Ok, really the last thing. As I said in point 1 above, if the business insists on not changing the budget allocation, you can still do RUP. You will have to modify scope to meet budget. You should still re-estimate and change the basis of estimate at each milestone and openly share the data.

Instead of seeking to change the budget, you are only seeking to get the "go/no-go" decision. Think of it this way. You are being completely honest, updating estimates based on new information. You can modify scope to maintain budget.

Now the client gets to make a decision:
1. Go. With the reduced functionality. Everybody wins.

2. Go, and you BETTER get it all done anyway. This one is childish nonsense, so just add it to the risk list. It is equivalent to demanding nine women having a baby in one month instead of nine. Demand all you wish, you ain't gonna get it.

3. No Go. If you can't get it all, stop now. This is a HUGE WIN. For once the client didn't have to spend all of the project's budget to walk away empty handed as they would have with a waterfall project.

4. No Go. But lets start a new project with the right budget. You lose some good data this way, but in the end they get the results and you get the budget.

5. My Favorite Analogy

Finally, this is my favorite analogy for helping people grant us permission to have sliding estimates. If you went to a mechanic and said "my car has a rattle. I want you to fix it, but first tell me how much it will cost." What would the mechanic say to this? Probably "Let me take a look at it and I'll give you an ESTIMATE." Interesting. 1. They get to look at it. 2. And at the end all we get is an estimate! Huh. And we say what? "OK."

Now software projects are FAR more complex than car repairs. Yet our teams don't get the same level of courtesy? If we forced the mechanic to give us an estimate (and he didn't just throw us out) he might say "other cars with similar rattles have cost somewhere between x and y, but I just won't know till I get a closer look." So, "Let me take a look at it and I will give you an estimate" is the same as Inception. "And at the end I'll give you an ESTIMATE." NOT "THE EXACT NUMBER ON MY WORD OF HONOR PLEASE VIVISECT ME IF I AM WRONG." Yet somehow we think it means this on a software project. Somehow the definition of "estimate" seems to have changed on us... "Let me take a look at it and I'll give you an estimate." is Inception. And you let all team roles look at it in their own special way, from analysts to testers.

Ok, so while we tremble at the thought of saying this in software, we agree to it for our car. We say "ok." Then what happens? A few hours later our phone rings. "Well, now that we have this thing taken apart, we can see a few other problems in here. Some you really should let us fix now. Others could wait, but would cost you more later 'cause we'd have to take her apart again, which will cost you. What do you think?" So the estimate sometimes changes. And what do we say? "Ok. Go ahead I guess." (note: some of you auto-savy folks may handle this differently, but the rest of us are a little more clueless and so we say
ok.)

That was Elaboration. Once we get our hands into the guts of a project, sometimes we find things out that you could never know till you got inside. Then you re-estimate based on this new knowledge plus the proven capability of the team.

So why do we accept this about cars, but not about software projects? Why do we say "ok" every time the mechanic says these things? Because we deeply understand the VALUE of our car. Sometimes we say "you know what? Forget it." One time I said "How about you just keep the car and we'll call it even on the labor to date?" Then we get a new car. Remember the 80/20 rule above. It only works if the VALUE of the project is well known to both sides. Customers will never go for re-estimates and will never participate in scoping until we PROVE we know the value of what is being built. Again, "Let's Get Real" will help you here, or take our Mastering Requirements Management with Use Cases class. Or both.

4. Use the 80/20 rule.

That last comment made me think of this thought. Imagine that the client asks for 100 features to be delivered in one year. In a waterfall project this is a common thing said one year later: "well, we don't have anything. But if you give us three more months we will have EVERYTHING." Yeah right.

Are you skeptical that this happens? Remember the chaos report, and probably some of your own project experiences. How many projects finish on time? In iterative development, at the end of the year we always have something, but often it is a subset of the whole. That is still a huge improvement over waterfall where you might have nothing.

Ok, so at the end of the year we have 20 of the 100 features implemented. When we tell that to the customer, how will they feel? Probably pretty unhappy. But only if we focus on counting features instead of focusing on value. According to the 80/20 rule, 80% of the value of a thing comes from 20% of the content of a thing.

If you listed the 100 things you liked least about your significant other, then fixed 20 of them, your relationship would be 80% better. Another example: 80% of the work gets done by 20% of the team.

You get the idea. So, if we picked the RIGHT 20% of the requirements, we might still deliver 80% of the value! If the system was going to grant $100K in new revenue, perhaps now it will only deliver $80K. If there was a business case for 100, there is probably one for 80. And remember the chaos report. Typically customers get 0%!

3. Who Has the Final Say?

We often get clients who say "We can't change the estimates, the resources or the scope. It is set in stone and final." So I like to reply with "Who has the final say in this?" Typically they say things like Senior Management or the Customer. The thing is that just isn't true. Visit www.standishgroup.com and check out the Chaos Report, or just trust your instincts: How many projects succeed on time, on budget, of value and with sufficient quality (the Rational definition of project success)? Back in '99 it was 9% for large company large projects. I believe that number is up now but still isn't above say 20%.

So who had the final say? I doubt it was Sr. Management or the Customer as probably 100% of them wanted success but only a fraction of them got it. They can stomp their feet and insist and threaten all they want, but in the end we can only do what we are capable of. It is important for them to remember this. Then we can say something like "Ok, so we can't do it all. I know this makes you upset. But we need to push through that and decide what is most important. If the most important thing is the date, then help us choose what subset to implement.

If you just stay angry and insist on 100%, in the end you will still get less, and WE will have been forced to guess what part to get done. Or worse, we won't guess, and you won't have anything at the end, except a promise that if you give us more time you'll get 100% someday

2. The Basis of Estimate

Learn to communicate about the basis of estimates. At the BEGINNING of Inception, if we were to give an estimate it would be based on some sketchy business case and risk list (if we are following RUP). What is the basis of estimate at this point? History. Gut. The SWAG (Scientific Wild A** Guess). Please don't get upset at the language, it is a shop term. Regardless the basis is not on anything specific to this project overall.

At the END of inception, we should now know the number of use cases, number of use case outline flows, number of use case outline steps, number of features, number of mechanisms, number of mechanism operations and more project specific measures. So now it is time to re-estimate, but notice we have a NEW BASIS OF ESTIMATE. Inception stuff. It is tough to argue with us at this point. The first estimate was a guess based on history. This one is a better guess based on tangible stuff. You can check our math if you like.

At the end of elaboration our basis of estimate changes AGAIN! Now it is based on ACTUAL PERFORMANC MEASURES. Since we have built a growing product during Elaboration (confused? Take the test on my blog!) we know the ACTUAL capability of THIS SPECIFIC TEAM on THIS SPECIFIC PROJECT. That is pretty hard to refute. Again we re-estimate and invite them to check our math. When the client sees the basis of estimate changing each time they will understand why we are doing this. And we do it every time, so they begin to get used to the rhythm of it. History, Inception Measures, Elaboration Actuals. Got it. Makes sense.

1. Learn How to Ask

Many IT teams automatically accept that the business will not change their funding and estimation models to accommodate IT's desire for a new process. That is not acceptable. You HAVE to ask and get rejected. It is NOT ok to assume you will be turned down and therefore not even ask. ASK. If they say no, add it to the risk and issues list and move on. Also, learn HOW to ask. I recommend "Let's Get Real or Let's Not Play" (the audio CDs are fantastic) by Mahan Khalsa. Basically you ask by asking them if they have any issues with how well IT projects are meeting their estimates and what other issues they have with IT. Then we show how the four phases of the RUP help to address their issues. Once they believe it, THEN we start to talk about the changes they should expect, such as to the way estimates are done, due to RUP. I LOVE doing these, as do many of my IBM Rational colleagues, so give us a call to participate on these discussions if you would like!

[rup] RUP and Budget Allocations

In IBM's RUP forum the following question was asked. I recommend joining that forum. Just send an email to majordomo@lists.us.ibm.com and put "subscribe rup" to join, and you will have access to a whole lot of experts (real and self proclaimed) as well as other practitioners just trying to succeed. For all posts from a forum I will use [listname] in the title to show what forum it came from as I did above.

To get a list of the other great forums to join check out this link:
http://www-128.ibm.com/developerworks/forums/dw_rforums.jsp
As of this post I am on rup, bizmod, otug, ruc, reqpro, lifecycle, uml. The link above can tell you what those are about and what others are available.

Ok so the gist of the post was this (I edited it a touch):
In my company, the budget for a project is allocated at the very start of the project but more importantly, the budget is allocated only one time!

So my question is, when it comes to contract and budget allocation, what are the impacts of a RUP adoption on these practices ?

My answer is this:
Adopting RUP often impacts the financial models of the company adopting it. This usually surprises people, but it is true. Most successful RUP Adoptions are successful _because_ of this impact, but only when the business buys into the change.

Specifically, the idea of "estimating once" changes, as well as the decision of which project expenses are "capitalizable" vs. "expensed." In a traditional waterfall project management model, early phases, such as planning, are typically not considered capitalizable. This causes them to think Inception isn't either, yet much of the work done in Inception IS capitalizable. Many people struggle with this and make the mistake of saying Inception (and worse Elaboration!) are not capitalizable on projects.

So be wary of how RUP impacts budget allocation practices as well as other financial considerations when adopting it.

The next few posts contain some more ideas on this topic.