Adopting the Enterprise Unified Process (EUP)

Figure 2 depicts a common strategy for adopting the EUP -- first adopt the RUP, tailoring it to your environment, and then tailor the EUP extensions on top of the RUP. The RUP product from IBM is a significant resource and provides an excellent basis from which to start. For a leaner resource, the Agile Unified Process (AUP) product from Ambysoft Inc. is also an option.

2. When to Adopt the EUP

3. Strategies for Adopting the EUP

There are several strategies which you should consider for adopting the EUP (or any process for that matter):

3.1 Assess Your Situation

You should start by identifying why you wish to adopt the EUP, perhaps for some of the reasons listed earlier, and then assess your organization against this criteria to define your capability gaps. This will help you to prioritize the changes you will need to make. You may wish to bring in an outsider to do provide a more objective viewpoint. Issues you should consider during your assessment include:

Current "pain points". What aspects of IT are you struggling with? Having problems identifying which projects to attempt? Are project teams constantly reinventing functionality that has been built by other teams? Do you have problems hiring and retaining good staff? You need to understand your problem(s) before you can identify the solution(s).
Existing RUP/AUP expertise. Does your organization have experience in the basic RUP/AUP approach? If not, then you first need to gain experience (and success) at an appropriate base software development process before considering the EUP.
Acceptance of an evolutionary (iterative and incremental) approach. This may be your biggest challenge if your staff only has serial/waterfall experience. It is very easy to say that you need to develop working software each iteration, but very difficult to grasp the implications if you're used to identifying all of the requirements up front, then doing all of your design, and so on.
Enterprise outlook. How well do your teams/groups/divisions/organizations work together? How well do the group(s) representing users work with the technical staff? Many project teams are used to developing systems in relative isolation, they're not used to following a common architecture, common guidelines, or even to consider the implications of what they're doing when it comes to operating and supporting their system once it's in production. Adopting the EUP will require adopting a more mature outlook than many IT professionals are used to.
Acceptance of change. How well does your organization respond to change? What percentage of your staff is open minded enough to consider trying new ways of working? How many are skeptical but open minded? How are unlikely to change at all? You are likely to find the book Fearless Change to be of interest.
Process culture. Is your organization used to a rigorous/prescriptive approach? An agile approach? No formal process at all? Rigorous folks will like the EUP, agile folks will demand that it be instantiated simply, anti-process folks will fight you all the way. You likely have all three groups within your organization
Technology expertise. For example, if you are switching to a service-oriented architecture (SOA) approach and you haven’t done it before, then you'll need to train your staff in these techniques and technologies. It is not simply a matter of sending people to Java or web services training, they'll also need architectural training and maybe even OO training, both of which take a long time to pick up.
Testing expertise. Do you have the testing expertise to support your effort? Testing plays a large part in evolutionary development because you test as you work, in fact many developers even test first. My philosophy is that if it's worth building, it's worth testing. The Full Lifecycle Object-Oriented Testing (FLOOT) method may provide some insight into the challenge that you face.

3.2 Take an Evolutionary Approach

Just as an evolutionary approach to software development is usually more effective than a serial one, so is an evolutionary approach to adopting the EUP. Start with the tailored RUP portion of Figure 2. Get that working in your particular organization first to demonstrate that you can handle developing object-oriented project iteratively and incrementally.

Then, based on your prioritized needs based on your assessment efforts, start adopting portions of the EUP. Perhaps your operations process is in dire need of repair, so adopt the appropriate portions of the Operations and Support discipline and perhaps the Enterprise Administration discipline. Once you're successful with that, an effort that could easily take a year or so, you might want to tackle Portfolio Management. Then Enterprise Business Modeling and Enterprise Architecture in parallel, quickly followed by the Strategic Reuse discipline. The point is that you can't adopt the EUP all at once, therefore you should adopt it a portion at a time, starting with your highest priority issues first.

3.3 Prove it in Practice

Adopting a process for an organization is not simply a matter of buying the RUP off the shelf or a few books and telling everyone to start following them. You shouldn’t look at any process as being the answer for your particular organizational needs. With the EUP (and RUP), treat it as a process framework, not a process. They provide the framework for you to decide what portions you will implement and how you will do so.

It should be proven out by actually running a project with it. For this, you should run a pilot project. Pick a pilot project that meets the following criteria:

3.4 Train and Mentor People

You’ll most likely need several training offerings, targeted to different audiences. Everyone will probably benefit from an overview of the process that explains what the new process is in general terms. Other than that, you’ll have to assess your needs. You may decide that a class discussing the iterative and incremental approach would be most beneficial. The choice is up to you – what makes sense for your organization? Your organization assessment should be the driver on what training you require.

Most likely, your people will need formal training in not just the software development process but in other skills as well, e.g., OO, Java, capturing requirements with use cases, and so on.

Much of the training will be targeted to project team members: project managers, analysts, architects, developers, etc. However, make sure that executives and senior management are properly trained, also. They need to understand the process so that they know what to expect. The people that project managers report to definitely need to be up to speed, as they will be the ones giving the PMs direction and reading PM’s status reports. Senior executives need to know what to expect from their direct reports and how the new process will affect their IT planning.

Keep in mind that training is a start but it may take a while for people to develop fundamental skills. An analyst new to use cases can be taught the basics of capturing requirements using use cases but it will take a while for him/her to develop the fundamental skills on how to do it properly. Do not expect people to become experts after a round of training. In fact, do not expect them to necessary be proficient right away. Some skills take time to develop, and may only come about as the result of mentoring.

One technique to help your organization get up to speed on your process is to bring in mentors. Mentors are people skilled not only in the specific skill areas that you need (EUP, OO, etc.) but, more importantly, at knowledge transfer. Mentors objectives must be not to make sure that your projects are on time and within budget (that’s the project managers job) but to get your people up to speed on specific skills as soon as possible. Use them to help speed up the learning curve for your people.

The best mentors are the people who have been there and done that. Keep that in mind when you staff your pilot project. The people on the pilot project will often end up as mentors to others in the organization. They should have the skills necessary to work with others and transfer knowledge on how to apply the process.

Your implementation of EUP will likely be different from XYZ Corporation’s implementation. If you plan on bringing in outside consultants to help mentor others, bring them in early so that they can learn with you what works and what doesn’t work for your organization so that they can mentor others accordingly.

3.5 Treat it Like a Project

When adopting the EUP, or any software process, it is vital to manage the effort just like any other project. Too many organizations decide that all it takes is a decree that ‘we’re going to use RUP/XP/FDD/AUP/...’ and that they will immediately reap untold benefits. That will not happen. Like any other complex effort, it must be managed properly. This means planning, communicating, managing of people and resources, etc.; all the things you do on a normal project.

If you are going to implement the EUP, one way to do this is to treat it as an EUP project. Follow the phases of EUP:

3.6 Gather Metrics

You’ll want to start gathering, and acting on, metrics as soon as possible. Continuous improvement is where you want to be and metrics help immensely in that regard. They can give you definitive measures on how things are proceeding. Be careful about metrics, though. Reporting the wrong information based on metrics or interpreting them incorrectly can do significantly more harm than good. Know and understand – and be able to effectively communicate – each metric you select; if you cannot do this, ask yourself “why” that metric is needed.

3.7 Don't Stop Improving

Process improvement is an on-going effort, which is why the EUP includes the Software Process Improvement discipline. Do not become complacent; look for ways to improve. Be prepared to respond to a changing business environment, where priorities may change.