Project management and the rational unified process for software development projects
Assistant Vice President Information Systems, Ohio Casualty Group
As a new I/T Program Management Office (PMO) within a mid-tier Property and Casualty Insurance Company, our primary goal was to implement standard methods and processes that would improve our delivery of software development products. On a Capability Maturity Model Integration (CMMI) scale, we were solidly a level 1 with very few repeatable processes. Our past successes were primarily based on the individual talents of our staff and their longevity with the organization.
The PMO’s first decision was to standardize on A Guide to the Project Management Body of Knowledge (PMBOK® Guide) as the basis for our project management methodology. Shortly thereafter, we selected the Rational Unified Process as our standard software development methodology. This paper focuses on our efforts to integrate the two methodologies and how they work in unison to provide a solid framework to meet the goals of a software development organization.
State of the Information Technology Department in 2002
Gambling on Success
Limited Standards and Processes
As an in-house organically grown I/T Department throughout the 70’s, 80’s, 90’s, and into early 2000, our standards primarily centered around technology and coding standards. We were entrenched with mainframe based legacy COBOL applications but had begun developing business critical applications utilizing Java technology and newer distributed architectures. Our documented standards were maintained in the ‘I/T Handbook’ or better known as the ‘Gold-Book’ because it was maintained in three-ring gold binders that were distributed throughout the department. I recently walked through the department and found a copy of this manual on one of our senior developer’s bookshelves. Even though it had not been updated since November 15, 1996, I can only assume he found comfort in keeping it around. I guess this rebuffs the old theory that software developers do not appreciate standards.
The same staff of developers, who were basically reacting to the squeakiest wheels, handled all new project request and maintenance activities. I/T Service Managers responsible for defined computer systems were our acting Project Managers but their range of responsibility was very broad and required them to focus much more on service than project management.
The “Waterfall Process” was the closest thing we had to a defined software development process.
Still a viable solution today, it was more of a practical approach to developing software vs. a best-practice approach. The greatest downfall to this approach is that it assumes all of the requirements can be gathered initially in a project and that they will not change prior to being delivered. As everyone knows, this is rarely the case and the end result is usually rework or a solution that doesn’t meet the present day needs of the customer.
With the practices outlined, it was very difficult to tackle a project of any size, set customer expectations and deliver on those expectations. Delivery dates were often missed, the scope of the projects were many times diluted to try and meet projected deliver dates, or the quality of the overall product was suspect because ample testing didn’t occur. The end result, right or wrong, was that in the eyes of our business partners, I/T appeared to have dropped the ball when project expectations were not met. With all of that said, I am not attempting to portray a department that didn’t provide value to the corporation because the facts are we did. However, our successes were primarily due to the heroics of a few. These were the individuals that exuded talent, knowledge, and commitment to getting a job done. Most had extensive seniority in our organization and understood how and why certain things were done in other systems. Many times this enabled them to leverage their knowledge and push the right buttons to deliver a product, like a hero.
Implementation of the Program Management Office (PMO)
A Focus on Best Practices
The Selection Process
In 2002 with a new Chief Technology Officer coming on-board, one of his first actions was to implement a new unit within our department that would be known as the I/T Program Management Office (PMO). The goal of this organization would be to identify and implement best practices in support of delivering software development projects in accordance with the triple constraints (on time, on budget, with quality).
The PMO’s first objective was to identify, document, communicate, and support the implementation of a standardized Project Management Methodology (PMM). We elected to base our methodology on the Project Management Institute’s (PMI®) A Guide to the Project Management Body of Knowledge (PMBOK® Guide) . The primary reason was the worldwide acceptance of the PMBOK® Guide as a framework for project management best practices. Secondly, this framework enabled us the flexibility to customize the specific implementation to meet the needs of our organization. Additionally, we created a new job description within our organization titled Project Manager that now reported into the PMO. The Project Management Professional Certification (PMP®) program that is based on the PMBOK® Guide was very attractive us.
The second objective was to select a Software Development Methodology (SDM) that we could purchase and implement within our corporation. This was more involved as we identified a number of vendors and submitted Request for Proposals (RFP). All responded and we went through a rigorous evaluation process. We were convinced from the beginning that we needed a SDM that was flexible in that one size does not fit all projects. Also, we were looking for a SDM that capitalized on evolving concepts such as use-case requirements, prototyping, and iterative development to name a few. Next, we were looking for a SDM that would support the PMM we had implemented. Lastly, we had a future objective of utilizing Carnegie Mellon’s Capability Maturity Model Integration (CMMI) as our metric for improvement within our organization.
|Maturity Level||Staged Representation Maturity Levels|
|1||Initial (processes are usually ad hoc and chaotic)|
|2||Managed (requirements are managed and that processes are planned, performed, measured, and controlled)|
|3||Defined (processes are well characterized and understood, and are described in standards, procedures, tools, and methods)|
|4||Quantitatively Managed (Quantitative objectives for quality and process performance are established and used as criteria in managing processes)|
|5||Optimizing (focuses on continually improving process performance through both incremental and innovative technological improvements)|
Thus, we were looking for a SDM that supported this model. IBM’s Rational Unified Process (RUP) appeared to meet all of our criteria.
Project Management Methodology (PMM)
With a decision made to base our PMM on the PMBOK® Guide , we needed to understand this framework enough to turn it into process and artifact documentation that could be used as effective communications to the newly formed Project Management staff as well as the pre-existing Service Managers. We began by categorizing projects according to effort and/or cost to complete. A project that exceeded predetermined cost or effort hours was deemed a large project, thus requiring a greater number of artifacts. We then identified mid-tier projects and small projects based on effort hours requiring a lesser number of artifacts. Again, using the PMBOK® Guide as our framework, we built a Project Management Checklist that identified required and recommended artifacts applicable to a project based on its categorization. Project Integration, Scope, Time, Cost, Human Resource, and Communications management were all initial project management knowledge areas we focused on in our methodology. We have since circled back around to focusing on Quality and Risk management and will eventually include Procurement management. In addition to our Project Management Checklist, we also developed a flowchart model for each project category that detailed each step of the project process with a graphical representation.
With our PMM documented, we were ready to begin the communication and training process. We created a PMO web site where a project manager can locate PMM documentation, templates, lessons learned, etc. We began holding bi-weekly Project Manager meetings where specific PM topics and lessons-learned were openly discussed. It addition, we identified incentives for Project Managers and Service Managers to achieve their PMP certification. The PMO supported management’s goal by coordinating group training, study groups, and providing approved study material. I am happy to report that 90% of our management staff have achieved PMP certification.
Creating a Project Portfolio
In concert with the development of our PMM, we were taking an inventory of our projects in an effort to provide a portfolio style view of our project suite. Previously, all of our I/T units within the department were tracking all of their projects using a myriad of tools. We began by focusing on the larger projects from each unit and manually entering the project specific information into a Microsoft Excel spreadsheet. We have since automated our project portfolio reporting using a Lotus Notes based project tracking system titled ‘Marin Research’s Project Gateway’. We are now able to provide up to date real time reports on our suite of prioritized projects to our entire staff and provide our Executive Management team with appropriate summary information so they can stay abreast of our key projects and initiatives.
Software Development Methodology (SDM)
Whether you are building software, a house or a bridge, a good PMM is applicable and greatly improves your ability to deliver the end product as predicted. However, there are underlying details applicable to each product that have associated best practices. For example, you wouldn’t want to begin building house walls on a foundation that wasn’t stable and/or approved. In a similar vein, you wouldn’t want to begin developing a software solution without a solid and verifiable architecture in place. This is where the Rational Unified Process (RUP) fits.
RUP takes an iterative or time-boxed approach to building software with the assumption that requirements come together over time and success and/or failure are better managed in smaller increments. RUP also promotes resolution of the greatest technical risks early in the project lifecycle. The traditional Waterfall methodology pushes risk forward in time so that it’s costly to undo mistakes from earlier phases. Building on Barry Boehm’s spiral model (Kruchen, 2000, p. 7), the identification of risks to a project is forced early in the lifecycle of an iterative project where you are in a better position to attach the risk. The approach is one of continuous discovery, invention, and implementation, with each iteration forcing the development team to drive the project’s artifacts to closure in a predictable and repeatable way.
To accomplish this, it has four major phases that are iterated through until the product is ready for delivery. Those phases are as follows:
Inception Phase: focus is on understanding the overall requirements and determining the scope of the development effort.
Elaboration Phase: focus is on requirements, but some software design and implementation is aimed at prototyping the architecture, mitigating certain technical risks by trying solutions, and learning how to use certain tools and techniques. The final product is an executable architectural prototype that will serve as the baseline for the next phase.
Construction Phase: focus is on design and implementation. Here, developers and architects evolve and flesh out the initial prototype into the first operational product.
Transition Phase: focus is on ensuring that the system has the right level of quality to meet project objectives; I/T staff fixes bugs, trains users, adjusts features, and adds missing elements. The final product is produced and delivered.
RUP is delivered as a software product that includes process documentation, templates, actor definitions, etc. RUP identifies numerous artifacts that are created throughout the project lifecycle to better manage the development of the end product. For example, an approved Use Case Model and Vision document are RUP artifacts that can be used to signal a successful end to the Inception Phase. An approved Software Architecture Document can be used to signal the end of Elaboration.
Integrating a Project Management Methodology (PMM) and the Rational Unified Process (RUP)
Although the RUP includes artifacts for a Project Management workflow, we found it to be incomplete to meet our needs. Thus like a picture that isn’t complete until you lay down a template over top of it, this is how I view our implementation of our PMM and the RUP. Once the picture and template were brought together, we held a number of “working lunch sessions” where we would walk through the integrated PMM and SDM process one project category at a time. This afforded the audience the opportunity to focus on a specific category of project and ask detailed questions. We did limit the initial sessions to Managers, Business Representatives, Architects and Senior Development staff members. We have since offered additional classes to all interested parties.
RUP has been installed for all of our management and architectural staff members to utilize. We are currently integrating our PMM web site into the RUP product for one stop shopping. Using IBM’s Rational Method Composer, RUP enables us to modify the purchased process documentation and tools to meet the customized needs of our organization.
Working in concert with each other, our two methodologies have created a very solid foundation that enables us to better deliver projects according to the triple constraints. Some of the benefits we have realized to date are:
- Disciplined scope management
- Early risk identification and mitigation strategies
- Increased productivity and time management based on iterative cycles
- Common project lifecycle language
- Increased customer satisfaction and quality
Our ultimate goal is to become a best of breed software development organization. To this end, we are using the CMMI model as a framework for introducing additional improvements into our PM and SD methodologies. We have found that the best practices we have implemented to date are also serving as a solid foundation for our continuous process improvement initiatives as we progress towards a higher CMMI level rating.
Kruchen, P. (2000) The Rational Unified Process an Introduction Second Edition. Boston, MA: Addison-Wesley
PMI( 2000) A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Newtown Square, PA: Project Management Institute
Carnegie Mellon Software Engineering Institute(August 2002). Capability Maturity Model® Integration (CMMISM) Version 1.1 CMMISM for Software Engineering (CMMI-SW, V1.1) Staged Representation Retrieved from http://www.sei.cmu.edu/cmmi/models/sw-staged.doc
© 2006, Mark D Robinson
Originally published as a part of 2006 PMI Global Congress Proceedings – Seattle Washington