So, how do you monitor and adjust a project? While it is not possible to do this constantly, it is both possible and desirable to monitor a project with some regularity. Here are some general rules of thumb: First, perform a project review at appropriate milestones in the project that fall somewhere between three- and six-month intervals; second, use an outside independent entity to perform the review–just as programmers should not test their own code, so those who run a project should not review it; third (and, by way of clarification, if it's necessary), a project review is not a project audit and should not be done by the internal audit department; fourth, while the areas of focus may vary somewhat from project to project, the following should be the subject of sustained scrutiny–business requirements, personnel, project management, and the vendor. Let's take a brief look at each one of these.

Business Requirements

The requirements statement is the “destination” and the “goal posts” for the project. Without clear and complete requirements, no one knows when the project is done and whether it delivered what it was supposed to. In the popular sports analogy, it's hard to score a goal if you don't know where the goal posts are. Business requirements include both high-level statements about the project's goals, end-state vision, and cost/benefit as well as midlevel and detailed statements of specific functionality. At the initial review, it is appropriate to focus on the project's mission statement, the end-state or to-be vision statement, and the cost/benefit analysis. In addition to assessing the plausibility of these statements, it also is important to ascertain the extent to which the project team understands and believes in these guiding documents.

In subsequent reviews, it is more appropriate to focus on the functional requirements that drive the activities of the implementers. Here again, a broad interpretation of “requirements” can be used as appropriate to include functional requirements, look and feel, performance and workflow, and process implications.

Personnel

Just as you can't score a goal if you don't know where the goal posts are, similarly you cannot win the game without a team of qualified players. There are two fundamental questions here: Does the project have enough resources, and do those resources have the right levels of expertise? Warm bodies and unassigned resources do not make successful projects. Expertise and experience are required in various key roles, including business subject matter experts, business analysts, system designers, software configurators and integrators, project management staff, quality assurance analysts, trainers, and change management experts. Obviously, not all these roles are required at all times during the project–requirements gathering comes before configuration/integration, comes before testing, comes before rollout–so, at different points in the project, different groups of personnel will be the focus of the review.

Project Management:

Following our sports analogy, project management is our game plan: the plans, approach documents, risk mitigation strategies, monitoring and reporting, and the strategy and tactics of playing the game to a successful conclusion. The project management also includes the project review actions. The project management review focuses initially on the organizing documents that set up the initial structure of the project–project charter, approach statements, team and governance structures, and initial phase plans. In subsequent reviews, the focus will be more the execution and monitoring aspects of the project, such as the detailed work breakdown structure, communications, risk and vendor management plans, and the frequency and accuracy of monitoring and reporting against plans. Other project processes, such as change management, also must be assessed. Later in the project, quality assurance, training, rollout, and change management plans and procedures will become the areas of focus.

The Vendor

Stretching our sports analogy a little more (but not a lot), the vendor provides the equipment, special team players, and the rules of the game. If the project is a core system replacement where the legacy system is to be replaced by a vendor “package,” then at least three major aspects of the vendor's offerings should be closely reviewed: the ability of the software to support the requirements; the expertise and effectiveness of the vendor's team in executing its part of the project and interfacing with the wider client team; and the appropriateness and robustness of the vendor's implementation methodology to organize the core activities of the project in an effective manner.

Conclusion

As noted earlier, it is unlikely all aspects of the project will be equally well supported at any specific point along the way. It therefore is important to view the project review process as an ongoing part of the project aimed at producing practical recommendations that improve the overall likelihood of project success. So, as also noted earlier, not only should each review change its focus as the project progresses through different phases, it also should review the results of recommendations and actions from the previous review.

We have used two broad metaphors to illustrate the nature of a large systems replacement project–the journey and the sports game. The project review is the monitoring and adjustment mechanism that guides a project to the appropriate destination and stops it from drifting off course. It also is the structural analysis that ensures the game gets played on the right field, by the right rules, with the right strategies, and with the right team.

George Grieve is CEO of CastleBay Consulting. Previously a CIO and still an acting consultant, he has spent much of the past 25 years with property/casualty insurers, assisting them in the search, selection, negotiation, and implementation of mission-critical, core insurance processing systems. He can be reached at 512-329-2619.

The content of “Shop Talk” is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.