By Ken Robb
It’s likely that at some point in your consulting career, you’ve been brought into an object-oriented application development (OOAD) project with a sordid history. This checkered past may have resulted from either a previous consulting engagement that failed or an unsuccessful implementation by the client. In either case, you’re asked to perform triage on the wounded development project.
In the past, I’ve been asked to do what amounts to an “architectural assessment” of a stalled or failed project. What became very apparent to me in dealing with these types of projects was that the cause of the failure was not entirely the fault of the technology but more so the failure to implement management principles, process, control, and design.
I suggest establishing a project management office to regain control of a failing object-oriented development project. A PMO should enable you to implement those processes and methods that help the organization not only meet its technical goals but also fulfill the most important requirements of all: meeting end users’ expectations and requirements and delivering a value-added application to the business enterprise.
- OOAD—object-oriented application development
- PMO—project management office
- UML—Unified Modeling Language
- RUP—Rational Unified Process
- RFP—request for proposal
- RFI—request for information
The purpose of an OOAD PMO
Establishing a PMO is a great way to install process and design principles “after the fact,” assuming that proper processes in design and methods were not used in the initial development of an application. Your challenge, as a consultant, is to show how these methods—specifically UML and RUP—can be introduced into an organization when software artifacts abound within the technical environment.
That’s where the PMO steps in. The primary function of the PMO is to exact control over the established development environment and create a communications channel involving the project sponsor, project manager, development team, and end users. The PMO guides the client through the implementation of these methods and processes and enables the client to improve documentation, process control, and testing environments, ensuring smooth development and management cycles with subsequent product releases.
Essentially, the PMO acts as an umbrella, integrating and unifying all the OOAD activities. The primary activities include:
- Software architecture assessment.
- Unified Modeling Language (UML) best practices.
- Rational Unified Process (RUP) best practices.
- RUP workflows and phases.
- Documentation procedures and policy.
- Comprehensive quality assurance environment.
However, use of these processes should not be the primary focus of the engagement. You need to gain control of the situation, and you need a quasi-political organization like a PMO to absorb and deflect those things that may have caused the original project to fail in the first place.
How an OOAD PMO should begin its work
Step one: Assessment, assessment, and more assessment
In order for you to find a solution, you’ve first got to know, in detail, what you’re up against. So before you start celebrating that newly inked contract, you’ll need to do the following:
- Determine whether an RFP or RFI was sent out for bid on this project.
- Find out who bid on the project.
- Analyze, in depth, the original business requirements. Chances are, they were underdefined from the beginning.
- Determine who the business owners are and, even more importantly, who holds the power over the project.
Now that you’ve got the whole story behind the project’s parameters, it becomes important to firmly establish your PMO team.
Step two: Establish the authority of the PMO
If your PMO is to be successful, you must establish the power and breadth of the PMO participants. They need to be pervasive within the organization—not just in the IT department. Introduce them by holding several meetings with different departments. For instance, hold a meeting between your team and senior-level managers from IT, sales, and operations so that you foster a greater sense of “team” development for the product.
Step three: Assess the architecture of the system
Assessing the architecture of the system you’ve been charged with bringing back from the brink is the next and most important IT step. Most developers refer to this process as reengineering or refactoring. Once you figure out where the project stands technically, you can begin working on a solution. As always, implementing process and control over the technical aspects—as well as the management facets—of the project will prevent this go-round from heading down the same dead-end path that led you to this project to begin with.
Allowing design to fall by the wayside and jumping right into code is the number one culprit for missed deadlines, budget overruns, and eroded team morale. In my experience, I grappled with the problem of introducing controls not only over the technical environment but also the management of the project. A PMO can come to the rescue in these situations to help you not only gain control of the uncertain environment left in the wake of a failing object-oriented development project but also to guide you in accomplishing your primary goal: turning out a useful solution.
Ken Robb is an information technology architect with more than eight years of development and systems design experience. He currently works as a principal consultant with Keane, Inc., focusing on e-commerce systems, legacy system migration, and development processes and methodology.
Have you successfully completed an OOAD project? How does this methodology stack up against your own? Post a comment below or send us a note.