The chief goal here is to identify projects that will contribute to the business mission of the enterprise and then provide resources for those projects to take shape. Three such development-like practices are business analysis, project development, and project scoping, all of which probably should be implemented at the senior management level. These practices, summarized next, can be used to shape the strategic direction and tactical focus of a development organization.
In corporate America, sometimes it seems that IT projects get pushed into production on the basis of either the “decibel principle” (whoever yells loudest) or the “density principle” (whoever can throw the most weight around). CIOs and their executive staffs often find that they are viewed by external business units as producers of products (i.e., solutions), rather thanshapers of products. Accordingly, they are expected to deliver whenever called on, often caught downstream of the initial decision to act. That line of separation, however, is not a productive one to follow. The business side of business and the technology side of business have become so integrated that there are no “sides” anymore, and well-thought-out technology solutions are essential to continued business success.
The organization at large needs to demonstrate its commitment to the project; this usually takes the form of capital investment. Then the sponsor needs to be identified, typicallyis a business manager, who will facilitate the exchange of work between the business specialists and the technology specialists. Two documents should emerge from the initial interactions between those parties. The first is a project charter, a formal description of the purpose and reach of the project. The second is the beginning of what might be called a script: a first draft of the business requirements, which will be used to guide the project.
By the end of Initiation, the organization may have appointed a specific project manager (or perhaps a program manager) to begin scoping the project. Based on the business analyses conducted as described, together with the charter and the business requirements, the major boundaries of the effort can now be established. Here the size, general cost, relative schedule, and release dates are documented; from these boundaries, detailed project planning can begin.
The goal here is to work out the details of project activities so that the effort can be tracked and controlled in an efficient manner, to meet the project’s initial boundaries of scope, cost, and schedule. Three events should occur in some form at this stage of an IT project: business and functional requirements development, plan development, and staff acquisition.
Treat the requirements definition activities as a project unto itself, with a fixed amount of time and resources in order to establish a baseline. The other is to use the available business requirements as a benchmark for initial scope, plan from there, and then provide for appropriate change control. Either way, the process starts off with a picture of what the end product probably should look like. The alternative strategy—and it’s the one many shops are drawn to, probably because it gives the impression of rapid progress—is to simply jump ahead into the unknown, trying to formulate a plan in the absence of solid expectations or common understandings.
Staff Acquisition
Talented, competent people are essential to the success of any project. A process will never replace that need; it complements it. Second, adequate staff preparation is essential. In all probability, the project manager has reached this stage with an objective, a charter, some set of requirements, and some initial planning data.
Plan Development
The big costs of an IT project come during execution, when the designers are designing, the coders are coding, and the testers are testing. A thorough and realistic plan will help the project manager control this capital- and resource-intensive phase of project work. Budgets, schedules, and logistics need to be worked out in detail, preferably with input from the project’s key stakeholders.
Phase 3: Execution and Control
The “real” work of the project is now ready to be implemented. The team assembles and begins working out a technical solution to the business need. This is the focal point of resource and capital expenditures, and it’s where most of the visible work gets done.
Change Control
The key is to not see change as disruptive but as a necessary component of solution realization. Change becomes problematic only when it’s out of control, when it is effected without coordinated purpose. Rampant and disjointed change can sink any project into a morass of budget, schedule, scope, and quality slippages. To help prevent such problems, project management should ensure that a proper form of executive-endorsed change control is in place for the project. The protocols set aside for this process should allow for the orderly submission of change requests, the evaluation of change impacts, and a manner of scoring or weighting the approval of change requests.
Progress and Performance Reporting
Communication should be a proactive, ongoing ingredient to all project activities. From communications comes information, and from information comes an understanding of where the project teams stand in relation to progress and performance. That’s the kind of reporting all project participants need—upstream and downstream—to appropriately focus their activities. Progress reports are akin to general status reports. They typically summarize schedule, budget, and resource utilizations against predefined benchmarks. Performance reports complement these by summarizing performance data as related to predefined performance and quality targets.
Phase 4: Closure
Although deployment is used as the final phase in the model presented in this chapter, the PMBOK wraps up a project with a closure phase. Closure is considered to represent the contractual end of the project, the point at which all work has been completed and all commitments have been met. Paperwork is now complete, and resources can be released to move on to new project work. Three activities typically take place around the time of closure: user acceptance testing, resource release, and a review of lessons learned.
At this point, the project manager probably is ready to formally release the project’s team members. This may sound like a trivial clean-up step, but it’s actually quite important, especially in larger organizations. A formal, prescribed release activity will help notify business units and teams across the organization that particular people are now free for assignment elsewhere. This coordinated control of resource availability lends itself to more effective planning and coordination on upcoming projects.