Ed Manley's Story
I tried the same thing [implementing all of Rational tools in one go], and got absolutely killed. I write this in hope that you can avoid some of these same issues.
Before the herein described experience I had worked for over twenty years as an independent consultant Business Analyst, specializing in requirements management and technical writing, and had used various Rational tools in nine different environments, and the Enterprise Suite in two. I am by no means a Rational tools or RUP expert - just a hack user of several of the tools - enough to get the job done with ReqPro or Rose, for instance, although I did at one time build and maintain the largest ReqPro SQL database among Rational's clients.
Shortly after coming aboard this company (I was hired to improve capabilities and implement process improvements in several areas) I decided that we needed methods and tools in so many areas that an enterprise suite only made sense. This was the first time I had seen an environment wherein every artifact of the Rational Suite made sense and was needed right away. Not a silver bullet, and not necessarily even the best solution in any given area, but so broad in its coverage and so integrated in its capabilities that it seemed to me the whole organization stood to make major gain. Besides, I have done enterprise improvement with individual tools, and know how painful tool integration and multi-vendor support can become.
You are way ahead of me already, in that the research and planning you have done reflects serious management commitment and interested, capable and dedicated resources. I failed to do this analysis and planning, as I assumed it was obvious to each individual how and why the Suite improved their particular lot in life - that, like myself, each would see a great opportunity and jump on it.
To make a case for my proposal I had Rational come in and do the Enterprise Suite installation for us, to give us a jump-start so we wouldn't have to spend resources on installation issues. I got permission to do this as part of an approved enterprise software development process improvement effort, as part of which we planned to install and try out the Enterprise Suite as a ninety-day evaluation.
Myself, as Sr. BA, our QA Lead, our Sr. DBA and two Sr. Developers were very excited, and were willing to do one of our upcoming software enhancement projects with the various Rational tools. (We are a fairly flat organization, wherein each of us serves as PM for our own projects, answering to one of two VPs). The rest of our sixty-or-so folks expressed various levels of interest, but no real enthusiasm - more of a "show me" attitude. I took it as good news that no opposition was voiced.
What killed us, however, was the enormity of the effort as well as a lack of planning, understanding and commitment at the individual level, and tepid management buy-in.
We had just launched a year-long software revision, incorporating some forty different enhancements that affected every part of our system. This enhancement effort, tied to the seven-hundred or so issues already in our issue tracker database, meant that all resources were already heavily loaded, if not actually overloaded, so I should have recognized that as a bad time to launch something as big as an Enterprise Suite rollout. Instead, I saw an opportunity to make the enhancement effort work better through the use of these tools, thereby proving my concept.
The three-man three-day client-server installation (two Rational experts and our Infrastructure VP) gave management their first hint that this software was huge - that it truly and deeply affected everyone in the company.
When management saw the huge learning curve and the amount of resources required to implement the suite I think they bailed, emotionally at least. While they didn't shut the evaluation down right away, they did go on about their business. Being new to the company I took their lack of interest to be a hands-off management approach. They have since hired a new VP of Technology to do these same things I was tasked with, and he shut it down until he could build a plan. That's where we still remain.
The perception quickly developed that we are in business to get software out the door - and time spent learning and implementing the Enterprise Suite would inhibit our ability to get product out.
Further, management is firm in their belief that not all improvement is good - that improvement for improvement's sake is not conducive to producing profitable software - that improvement is improvement only when it makes us more profitable in some direct way. They are indeed committed to quality, but committed to the concept of "just-enough" quality, wherein we produce a usable, working product that satisfies the client - and any quality improvement beyond that isn't profitable. Since these events took place I have come to discover that this definition of quality is widely held in IT management circles. Would that I had understood this from the start!
Then too, we had little credible proof beyond my word that adopting the Suite would make us a "better" organization, as my management defines "better", or any concrete examples that the benefits would outweigh the investment, beyond a few white papers, most of which don't deal directly with our type of development environment. Rational is all over the web thing, and that's not us. As a result few of the Rational papers describe things we do.
Management was basically willing to go along with me, and I should have seen that their "Show me what you've got" attitude was not the same as having their full commitment and support.
Rational begged us not to implement the entire suite - it took a lot of convincing to get them to support rolling out the entire suite at once. In fact, I had to escalate my demands for this to the highest levels at Rational before they would agree to do it. Even then they could not refer me to any organization that had successfully implemented the entire Suite at once. Guess I should have listened!
Needless to say, the evaluation went little further than the installation. We all already had a full-time job - getting software out the door, that did not leave much time for learning the RUP, much less the tools. I and the others mentioned above did our best to learn these things during off-hours and stolen moments at work - but when your time is tracked in fifteen-minute increments and all time has to billed to a project, you can imagine that the corporate focus was on projects perceived to get software developed, rather than processes improved.
The work you have done, as reflected in this conversation, is terribly important. Having only a vague idea of what these tools would do for us, of what we should do in our daily workaday habits to incorporate them, left us with no clear individual path. Looking back, my expectation that putting these tools in their hands would somehow lead to enthusiastic individual adoption was foolish. They needed to be told exactly what they were expected to do, what processes they were to follow, why and how to follow them.
The biggest obstacle was (and still is) the RUP. Since I was just learning it and nobody else had ever seen it, we had no valid product champion to help us map our way through it. Rational was willing and able to support us, but our people, most people I now suspect, are averse to picking up the phone or emailing someone and asking for advice. By simply throwing the RUP out there and expecting them to find and adopt the parts that affected them I inadvertently threw a huge, fairly indecipherable and wholly new development process at them. The perception is that the RUP calls for a paradigm shift in thinking - a whole new approach to our approach to the SDLC.
I embrace change, and jump on any opportunity perceived to improve my skills and capabilities. I assumed that each team-mate thought the same way. I was wrong!
As anyone but myself at the time might understand, it scared the hell out of them. Your work, as reflected in this conversation, will help each individual understand which 20% or so of the RUP applies to them, and help them map their way through it.
At this time we are discussing building our processes around concepts of the EUP and parts of Agile Modeling and XP processes, blending them into our legacy ways of doing business, and looking at tools for specific needs. The new VP of Technology is now driving that process, and I am, understandably, supporting it but keeping my opinions strictly to myself! Well, actually I talk to him about them, but that's as far as its gone. He tells me that some of my ideas are great, and he's working to implement some of them. I suppose what I am saying here is that you have to have the political and people skills to effect big change, as well as the patience to do this a little bit at a time.
In the meantime I have been tasked with revamping our documentation process, building a modular documentation management system, creating an online help system and putting our documentation on our intranet.
The end result, I fear, will be that we will in fact adopt the RUP and an enterprise suite of tools - only it won't be called that. Instead, we will have a piecemeal system of processes and tools built slowly (and expensively!) over a long period of time, cobbled together using CompuWare and others, to replicate what the Enterprise Suite could have done for us if I had but introduced it in a slow and methodical way.
To sum this all up, good luck to you. I hope that some of my experiences help you avoid the pitfalls and poor planning that tripped me up.
For What Its Worth Department:
Educate yourself first. You absolutely must have expert advice on hand for every affected area, process and tool. Hire expert consultants for the initial six months.
Get solid management support. Make sure they understand all areas that will be impacted throughout the organization.
Talk openly with management to develop a clear (written) understanding of their goals, needs, and definitions. What exactly is quality, and what investment is it worth? Discover what improvement means - if you see a field on a screen mislabelled, does your company consider it incumbent to correct it, or will they wait till a customer is willing to pay for the correction before they will do it?
Develop a core set of key requirements for each area, and explain how the RUP, UCM and Enterprise Suite fulfil each one.
If your plan or Rational's tools fall short in any given area, be open about it, and explain how you will overcome that shortcoming.
Remember that perception is everything! (Well, it's a big part anyway) Remember that your perception of their requirements, your perception of solutions, is not theirs.
Elicit requirements - don't deliver them.
Have all employees trained in the RUP (tailored to their applicable 20% if possible - analysts need quite different training in the RUP than do developers or testers!).
Get training in complementary skills such as OOA&D, Visual Modeling and UML - they can't use the tool if they don't understand the foundation it is built upon.
Map out UCM just as carefully as you do the RUP.
Get internal concurrence for and lead training sessions on your process and methodology ideas.
Get job-specific tool training for each individual expected to use the particular tool.
Publish the process knowledge you have learned on a corporate website where everyone can see it.
Publish the many white papers available as well, preferably categorized by topic or area of knowledge.
Organize team brainstorming sessions, wherein teams get together perhaps one hour a week to brainstorm who, why, how, where and what to do with these tools.
Listen to Rational. I am convinced that every Rational employee with whom I made contact advised me in my best interest, not as sales folk pushing a tool...even the salesmen!
Remember that not everyone thinks like you do, and not everyone supports your efforts.
The psychology of change must be considered. Individual and team dynamics are greatly affected - account for this. You can't force them.
Implement a lending library where corporate training literature, company-purchased books and individually-owned books and papers can be shared by all.
Do nothing quietly. Hoping to "slip it in" just won't work.
Implementing the Suite is, as has been pointed out, a whole lot more than installing it. [I am tremendously interested in how you do, so please keep me posted. - personal comment on RUP Forum]
Again, good luck! I am rooting for you.
Ed Manley