Q1: Can you Code in Inception?

Can you code in Inception?

The answer to Q1 on the quiz is YES. The fact is, if anyone ever asks can you preform RUP Discpline X in Phase Y the answer will always be YES. You can preform any discipline in any phase!

So the real question is: When or why would you code in Inception?

At the simplest: if while the Architect is comming to undestand the vision, they see a significant technical risk, you may have to code in Inception to resolve this risk. More specifically, the technical risk area needs to have two characteristics:A. The architect is unsure that a solution for the technical risk existsB. If there isn't a solution, we really have NO project.

This is not common on most projects, so coding in Inception is not common either. But when this combination occurs, we need to address it by creating a _throw away_ prototype. There are two basic kinds of prototypes, throwaway and evolutionary. In Inception we focus more on throwaway prototypes, while elaboration can be seen as an evolutionary prototype.

In a throwaway prototype, we throw away the solution and seek to only retain the knowledge that something is possible or is not. With an evolutionary prototype we keep the solution and incorporate it into the actual deliverable product. Thus a throwaway prototype can be of low quality, since it will be scrapped, but the evolutionary prototype MUST have a minimum level of quality or it will severly impact our product. Remeber that the evolutionary prototype is created to address a high risk area. The last thing we want is for a solution to a high risk area to be of poor quality and actually part of the final system!

Many projects spend far too much time in Inception. Some of my clients have spent as much as six months, when unguided. The first iteration of Inception should be much faster, say 10% of your project schedule or three to four weeks, whichever is SMALLER. Four things can drive this number up: Specifically, stakeholder interviews, Architectural Proof of Concepts (APOCs), weak domain knoweldge (which leads to using the RUP business modeling discipline), or adopting a new process or technology set.

Since speed is of the essence in Inception, we don't want to slow it down by creating an executable that we plan on keeping. Speed and Quality pull apart from one another. In Inception we focus on speed, which means we don't want to keep any prototypes created there.

What if you wish to retain the solution? Wait until Elaboration. The fact is that if you think there is a solution, then you always wait until Elaboration. It is only when you are worried there isn't one that you code in Inception. If you truly think there may not be a solution, why would you slow down enough to make the prototype high enough quality to keep, when it may not even work? So you could almost add a C to the above list:C: You are willing to throw away the solution and retain only the knowledge that the risk can or can not be solved.

Finally, one best practice to manage your Inception prototypes is a best practice I learned while using the Spiral Model for software development: For every prototype, have a statement that says "This prototype ends when..." then finish the sentence. One real world example from a client was "This prototype ends when we can connect to the vault using a com object, extract a single doc property and display it to standard output." Having a crystal clear statement like this one will ensure that the prototype can still be managed, even if they are not following a disciplined set of standards (remember we ignore these, reducing quality, but increasing speed for Inception coding).

As an example, a manager can use this list to manage the prototype: Imagine the APOC (Architectural Proof of Concept) is trying to solve a risk. We create a sentence that says "This prototype ends when XYZ". Then manager can now go to the assigned resource and say: "Can we do XYZ yet?" If the answer is "Absolutely! But look what else it does now! It does A and B and C and D!" At this point the manager can reel the developer in. They've done too much! "That's great, but we only needed it to do XYZ. Inception prototypes are the critical path for Inception, so as soon as you get XYZ done, you need to stop and report this so we can move into Elaboration! Also, remember we have to throw away all of that work due to low quality, so while what you can do is interesting, it has increased scrap for the project!"

Another possible response to "Can we do XYZ yet?" is "Oh... XYZ... right, um, no. Sorry I've been focusing on A and B..." The developer has lost sight of the target. Actually, with a well written "this prototype ends when" sentence, this is less likely to occur, but if it does the manager can now remind the developer that XYZ is all we need to get out of Inception, and to refocus their efforts on cracking that nut, or proving it can't be cracked. They can elicit a new estimate and move on.

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.

Transition

So Inception handled the risk of creating a project with insufficient value.
Elaboration handled the risk of selecting an architecture that couldn’t handle the high risk requirements.
Construction handled the risk of providing the most amount of the value we identified in Inception.

Transition handles the risk of a valuable project not being adopted into use.

Once we arrive at Transition, we have a complete valuable project with a good architecture. But we have to ensure that the target audience actually uses the product we’ve created successfully or that value is not realized.

Transition ends in one of two different ways, depending on the business you are in. Either it ends with “End Of Life (EOL)” or with “Release.”

If you are responsible for maintaining the product until the product is retired, then Transition ends with EOL. This means that you will continue to add maintenance iterations onto the plan for a long time to come. You will have iterations that basically implement groups of change requests, then release a product upgrade.

If you ever receive a change request that is architecturally significant or that radically changes the vision, what do you do? You probably guessed it. You start a new generation with its own IECT phases. Inception: Does this change have value? What is its scope? Elaboration: Let’s change a small part of the system to prove the architecture will work. Construction: Let’s change the rest providing as much value as we can based on time constraints. Transition: Let’s support the new version.

If you do not have the responsibility for maintenance, then Transition ends with “Release.” This can be because another group will be doing the support, or because you will be turning the source over to a client, etc. In this case Transition is finite and ends when the client or maintenance team accepts that they can successfully own the product now.

Construction

Inception handled the risk of building a project that had little or no value.
Elaboration handled the risk of building a project whose architecture could not support the high risk requirements.

Construction handles the risk of providing the most amount of value possible given the time constraints on the project.

By the time we get to Construction, we are sure that the project has value, and we are sure that the architecture is valid and will support the solution. Now we must build as much of the feature set as we can to provide the most value to our customers.

So there is an interesting point to understand here for a RUP project. Most people will say that value to the customer should drive development. In a RUP project this is true during Construction, but in Elaboration technical risk drives the project. In other words, during Elaboration, the Architect picks what we work on based on highest risk first, NOT based on highest value! But then during Construction the RUP Systems Analyst (a.k.a. Business Analyst, Requirements Owner, etc) picks what we work on based on highest value first.

Another interesting point is that other than how we pick what requirements we are going to implement, the tasks on the iteration plans for iterations in Elaboration and Construction are nearly identical! There are some architectural tasks that we can skip in Construction, but overall the work is quite similar. The main difference is that the work in Construction is less risky as we’ve already created an architecture to follow and proved that it will work.

By the end of Construction, the product is complete, or as complete as we could make it, and provides the most amount of value possible.

Elaboration

Inception handles the risk of investing in a project that has no value. Therefore, if we get out of Inception and the project is still a go, we can be sure it has a strong business case.

Elaboration handles the risk of building a project whose technical architecture can not support the requirements for the system.

Many software projects fail due to selecting the wrong architecture. In Elaboration we must prove that our architecture is valid. In a waterfall project, the architecture is a “paper architecture” which means that it is sketched out and then we say we have defined our architecture.

The RUP requires that we create an “executable architecture.” This means that not only must we create our paper architecture, we must then prove that it works by selecting the highest risk requirements for the system, implementing them, and testing that they work correctly using the selected architecture. Also, by actually implementing part of the system we can determine if the paper architecture was correctly rendered (which in most cases it was not) and then improve it.

Elaboration has another purpose. In Inception we create a high level scope of our project and capture that in a Vision document. During Elaboration, we often discover that our Vision was not correct, and we adjust it based on what we learn during Elaboration. The customer, when they see the results of an iteration often need to adjust their request now that they better understand the solution. Also, the architects tend to learn a lot as well and also can reshape the Vision based on what is learned during the iteration as can other team members as well.

So, your project has entered Elaboration when we have proven it is of value. The project leaves Elaboration when the Vision has stabilized and the Architecture has been proven through a prototype that is tied to the real high risk requirements of the system.

I will cover the details on how to make this happen in part 2.

The RUP Phases: Inception

Ok, so now you should understand that a RUP project, software oriented or otherwise, should go through the four phases IECT. Also each phase can have one or more iterations that it guides. Let’s talk about what those phases mean.

Each phase was created for the RUP to handle a different type of project risk. Inception handles the risk of building a project that has no value to the organization. The term “Business Driven Development” is very popular, and gets at the idea that we have built far too many projects that don’t actually provide value.

As an example, I was at a Ship and Check, and wanted to know how much it would cost to ship a TV from Detroit to Phoenix. If the cost was too much (it would only cost about $250 to buy a new one) I was hoping to sell it. I noticed that the clerk looked up the cost in a large book. So, being in this line of work, I said “I’m surprised they haven’t automated that lookup.”

The man answered “It is. This computer right here can do it.”

So I, always the analyst, asked “Why don’t you use it then?”

“Well, it is actually faster to just use the book.”

Now there are lots of possibilities here. The problem could be a training issue (covered in the Transition phase of RUP), or it could be that the selected architecture was too slow to compete with a manual lookup (web based vs. stand alone client). But it also could be that the automation of the lookup really didn’t have value! It is possible that some executive said “Let’s automate that lookup.” Imagine the cost of creating the software correctly, then installing it in all the stores and training the folks to use it only to discover that no one does!

Many companies have created software that works as specified, but that provides no real business value back to the organization. The purpose of the inception phase is to get the team to quantify what the value of the project really can be, and to scope what needs to be done to get us to that value at a high level.

For the truly curious, it would have cost about $200 to ship the TV. I offered the TV to the ship and check clerk for $100 and he took it.

Phases and Iterations

Ok, you’ve taken the quiz, lets start defining the phases. You may have heard definitions before, but as promised, I believe that you will find a clearer definition here than you have found before!

First off, how do the phases relate to iterations? That was the topic of question 5. Basically, the best way to understand the phases is to first get rid of them altogether. A project can be iterative without following the RUP. Imagine that you decide, based on some criteria, that you want to try to build a complete product in nine iterations.

Each iteration, if you are truly doing iterative development, you would travel through all nine software disciplines (Project Management, Requirements, Analysis and Design, Implementation, Test, Deployment, etc.) in each iteration. Each iteration would result in a partial solution until the whole solution was at last available.

But a question usually comes up when people first look at this approach. “How do we select what we do in each iteration?” That is where the phases come in to play.

RUP can guide any project, even those that have NO software component. This is why they have an “implementation” discipline instead of a “coding” discipline. Implementation = coding if you are doing a software project. But if you are doing a non software project, implementation would be whatever it takes to go from detailed designs into a real tangible solution.

Basically every RUP guided project, software or otherwise, goes sequentially through a set of four phases. A phase is sequential and you can’t go backwards. These four phases are Inception, Elaboration, Construction and Transition. By understanding what happens in each phase, you can then understand how to choose what work to perform in each of your nine iterations.

At this point, it should be clear that the answer to question 5 is A, not B. In ‘A’ the project goes through each of the four phases once. In B, you go through the four phases again and again, and this is not possible.

For example, let’s imagine we are talking about a human’s life. Inception = Infancy, Elaboration = Teenager, Construction = Mid Life and Transition = Senior Citizen. If in your Mid Life, you realize you wished you did things differently when you were a Teen, you can take corrective action in your Mid Life, but you can’t go back to being a Teen!

There are two reasons people sometimes pick B. 1. They equate each iteration to a “generation” of the project that is to be externally released. Under this interpretation, each iteration is actually a full project, and each project goes through IECT.

2. They equate I to Planning and Requirements, E to Design, C to Code and T to Deployment. In each iteration you really do go through all those disciplines, but equating the RUP phases to waterfall phases is actually incorrect. More on why later, but this should tip you off that the answer to Q4 is actually No. I’ll provide more justification on that later too.

More iterative or more waterfall?

I often ask my clients about their current process when helping them transition to the RUP. One question I like to ask is this one: “Is your process more iterative or more waterfall like?” Some don’t know what waterfall means, so I explain it and they realize that they did know what a waterfall project is, but they just didn’t call it that.

Anyway a large portion of my clients say “we are more iterative.” When I hear this I like to follow up with these questions: “Do you do gather and detail all of your requirements at the beginning of the project, or do you gather and detail the requirements each iteration?” The usual answer is “well the requirements we do at the beginning or else we really couldn’t scope the project.”

The second question I like to ask is “do you do your system test on an actual executable product at the end of the project or during each iteration?” The usual answer is “well we do unit test each iteration, but you can’t do system test until the system is built at the end of the project.”

So they do their requirements at the beginning of their project, they do the system test at the end of their project, but they claim their process is more iterative than waterfall. What are they doing iteratively? Don’t confuse having builds with iterative development. It is not enough just to do the design and coding in iterations, it is the whole lifecycle that needs to be iterative.

A question that often comes up here is “if we don’t do all of our requirements up front, how can we manage the scope of our projects?” I’ll answer that question in a separate post.

Question 5

Which of these is the correct interpretation of RUP phases vs. iterations?

Imagine that you have a project that will be completed in nine iterations. We will refer to the nine iterations as I1, I2, I3… I9.

Which of the following would be a correct application of the RUP?

A.
Inception will have I1 and I2
Elaboration I3, I4
Construction I5, I6, I7
Transition I8, I9

Or B.
In I1 we go through Inception, Elaboration, Construction, Transition (IECT)
I2 again IECT
I3 IECT
I4 IECT
…
I9 IECT

So A shows that iterations belong to a single phase, while B shows that iterations consists of four phases each.

The Ultimate RUP Quiz

* Q1: Can you code in Inception?
* Q2: Is coding typical in Elaboration?
* Q3: Is writing detailed use cases typical in Construction?
* Q4: Is this a good approximation for explaining the RUP?
(RUP Phase) = (Waterfall Phase)
- Inception = Planning
- Elaboration = Requirements and Design
- Construction = Code
- Transition = Test and Deployment

So the quiz is really testing people’s understanding of the four phases of the RUP, Inception, Elaboration, Construction and Transition. I won’t answer the quiz right here so you can think about the answers and look for them later in the blog. Do your best to answer them, even if you don’t know the four RUP Phases. They do occur in chronological order, so you should be able to guess at the answers.

It is ok to be wrong. It is not ok not to play!

Do You REALLY Understand the RUP Phases?

Hundreds of my clients claim that they already understand the RUP. I always push on this because I find that most people who say they understand the RUP really don’t.

I have devised a fascinating quiz to help prove this point. It is fascinating because I have given it to literally over a thousand people and almost all have failed to get the questions correct! Yet I have also given it to IBM Rational Technical Specialists, and 100% of them have gotten 100% of the questions correct!

This tells me that the RUP is not great at communicating itself. I would love to be put in charge of fixing this problem, but in the meantime, this issue ensures that I will have lots and lots of work available to me helping folks to understand and adopt it. It is possible that no one could make it self adopting without consulting, but I’d like to imagine it could be done.

Ok so on to the quiz. The quiz consists of five questions. The first four questions are yes/no questions and the fifth (a newer addition to the quiz) is a pick choice A or B. These questions are NOT meant to be trick questions. The answers are obvious to those who know the RUP and a mystery to those that don’t.

When I give the quiz to Rational employees, the results are always interesting. If the colleague is new to the company, they hem and haw for a while but eventually, with lots of caveats, give me all the answers correctly. They are afraid to be the first internal person to get one wrong. But they don’t.

Meanwhile when I give it to a veteran colleague, they answer quickly and with an almost defiant air. Then they say, “and if you disagree, it is you that are incorrect in your interpretation of the RUP, Anthony.” Yet they give the same answers. The real difference is that they are confident in their understanding of the RUP!

OK, so here are the questions. Good luck! Oh and remember they are not trick questions. It is not “wordplay.” For example, when I say “typical” below, what I mean is that if you looked at 100 projects, most would have some characteristic.

Part 1: RUP Basics

One thing that often confuses people is that RUP is both a process and a product. I’d like to start by clarifying the difference between them.

When people first start looking at the products and services of IBM’s Rational brand, it seems overwhelming. But the RUP is the thing that ties it all together. All of the products, consulting services, instructor led and web based training that they offer are there to support the RUP’s six best practices. So basically if you understand the six best practices, you understand if Rational has a solution that could help you.

The six best practices are:
* Develop Iteratively
* Manage Requirements
* Use Component Architectures
* Model Visually
* Continuously Verify Quality
* Manage Change

So every product, service and training class in the Rational brand are there to help you succeed in these six areas, and the RUP process describes the approach to take to achieve this improvement.

The RUP product, on the other hand, helps to deliver the RUP process into the hands of the team. Basically the tool consists of four major parts.
* Process Delivery Tools
- Workflow
- Roles and Responsibilities
- Templates
- Examples
- Tool Mentors
- Guidelines
- Checklists
- Etc.
* Process Configuration Tools
* Process Authoring Tools
* Community Tools

The “Delivery Tools” get the RUP process into your hands by defining the workflow for nine different disciplines, such as requirements management, the roles and their responsibilities, templates for their artifacts, etc.

The “Configuration Tools” let you customize your version of RUP with your own process assets or with various RUP “plug ins” that center around other process or technologies, for example there are plug-ins for “XP,” “User Experience Development,” “COTS selection,” “J2EE development,” etc.

“Authoring Tools” allow you to create your own processes in the same style as the RUP and to create plug-ins like those listed above.

“Community Tools” are about the forums that exist (and even this blog!) to help you adopt the RUP successfully.

In this blog, I assume that you have access to the RUP tool. Even if you don’t I think you will derive huge value from the posts I put here, but to really maximize your chances of success, having a license of RUP will greatly help. And happily, it is the least expensive Rational tool by orders of magnitude.

Introduction (The First Post!)

This blog will help readers understand the Rational Unified Process. It will cover both how to use the RUP successfully on a project as well as how to deploy it in an organization. I plan to start with an introduction to iterative development, the most confusing part of RUP, then move into how to use it on a project, and then how to deploy it in an organization, however I will go whatever direction the blog seems to flow.

For the last six years I have worked for IBM Rational, helping customer to understand and adopt the RUP. In the last few years, I have introduced RUP to over 700 IBM Partners, to hundreds of IBMers during internal IBM educational events, and to attendees at the 2004 Rational Software Development Users Conference.

Now here's the thing. While many self proclaimed RUP experts have been thrown out of accounts due to an inability to show tangible results, over the last six years, I have had zero dissatisfied customers, and this is among literally thousands of software professionals as well as managers, directors, VPs and CxO level professionals. Because my approach to helping people understand the RUP is so unusual and so effective, hundreds of my colleagues and clients have asked when I will finally write a book.

This is where this blog comes in. I am at my best when I am teaching others about the RUP, rather than just narrating about it. So, I plan to start by sharing some great gems, but I am avidly hoping that questions will pour in allowing me to answer them in the blog, which is my best mode for communicating the RUP. Eventually I hope to then transfer all of that to a book.

Enjoy!