Project managing the SDLC
using milestones to align project management and system development lifecycles and report project success
As a Project Manager of a System Development effort, you are responsible for keeping the performing organization's management informed of your project's progress. In this session, we will deal with three challenges inherent in this responsibility: reporting meaningful milestones; reporting progress with the right frequency; and finding a way to highlight the value of your project management contributions.
The Project in Context
First of all, let's consider your project in the context of a typical organizational structure, illustrated in Exhibit 1.
You need to communicate the status of your project and the progress it's making to a broad variety of stakeholders: technical chip-heads, financial bean-counters, functional SME's, and level upon level of meddling managers and executives. All of them have different needs for project information, yet the most common vehicle of communication available to you is the weekly status report, while the most frequently used communication forum is the weekly status meeting. That works for the folks that are enmeshed in the details of your project – the project team members – but it is too granular for Mr. Bigpants whose eyes glaze over during the status meeting you've managed to drag him into, and who never has time to read your voluminous status reports.
What you need is a way to report milestones that can be utilized to keep all layers of management, on both the technical and business sides, apprised of the project's progress in a way that is meaningful to them while reflective of your contributions. There is a vehicle you can use for that purpose – most likely, your boss either prepares or participates in the preparation of some sort of a periodic (usually monthly) report that goes upstairs. If not, a monthly email will do. But whatever form it takes, you need to have a series of appropriate milestones that you can report accomplished on that periodic schedule. In order to come up with them, we need to consider, and align, the Project Management and the System Development lifecycles, and determine what deliverables (on both sides) can serve as reportable milestones.
The Project Management and System Development Lifecycles
A generic project management lifecycle is illustrated in Exhibit 2. It consists of four main phases, each comprising certain processes, with each process producing certain Project Management deliverables.
Producing the Project Management deliverables depicted above is a key aspect of your responsibilities, yet they obviously should occupy different strata of the corporate awareness. While producing a list of project risks is an erstwhile and necessary activity, it would hardly get you a pat on the back at a corporate powwow. Nailing the project's scope, though, could, provided the project is large enough, while having a schedule that everybody agrees to, should, and getting all decision makers' sign-offs on a definitive blueprint for the project (otherwise known as the Project Plan) definitely would merit approbation of your Executive Sponsor.
Picking the right PM deliverables as your milestones, then, not only allows you to report your project's progress, but also lets you highlight your contributions to the project's success, proving (or reinforcing) the value of Project Management to the organization. The next challenge is to align the PM milestones with the deliverables that everybody really cares about – the outputs of the System Development Lifecycle.
A generic system development lifecycle is illustrated in Exhibit 3. It consists of four main phases, each comprising certain processes, with each process producing certain System Development deliverables.
The same considerations (which deliverables are meaningful to various layers of management) apply here as well. Nailing Functional Specifications, obtaining agreement on a system prototype, and getting system acceptance signoffs are all understandable and laudable achievements; but touting the delivery of a system standards document, or boasting at length about flawless unit test results, may result in stifled yawns among the executive hair crowd.
There is also an additional consideration of the passage of time. From the point when Technical Specs are produced, until the project team is confident in system test results, a lot of water has gone under the bridge. The project cannot afford to be inside the “black box” (remain incommunicado) for that long. Fortunately, most systems are not produced all at once, but are developed one subsystem at a time; and it behooves the Project Manager to regard – and report – each one as its own accomplishment.
Aligning the Lifecycles
Having achieved some understanding of the Project Management and System Development lifecycles, and having learned to discern relative value of their multitudinous deliverables, we are now well positioned to come up with a sequence of milestones that can communicate the status of the project in a fashion meaningful to the Project and Executive Sponsor layers of the organization. To do that, however, we first must align the two lifecycles and understand which project management processes facilitate development of technical deliverables, and which system deliverables must be completed in order to satisfy project management objectives in each phase of the lifecycle.
We'll start with aligning the lifecycles at the phase level. The first phase of the Project Management lifecycle is Initiation. In order to complete this phase, and produce the expected deliverables such as initial project scope and schedule, it is necessary to take some measure of the required system. Hence, the Requirements phase of the System Development lifecycle appears to map logically to Project Initiation. The Planning phase requires far greater precision in estimating the size, complexity and impact of the expected system; such detailed planning is only possible after definitive conclusion of the activities inherent in the Design phase of the SDLC. Planning, then, logically maps to Design. Execution, on the other hand, encompasses all the activities up to and including system deployment; it is not useful to initiate Closeout and identify lessons learned until all the lessons have been learned! So Project Management Lifecycle phase Execution logically maps to System Development Lifecycle phases Construction and Implementation. The Closeout phase stands alone, outside of the system development lifecycle.
The above mapping is represented in Exhibit 4.
Once again, it's important to reiterate that in real life, the distinctions are not as cut-and-dried. It is possible, indeed likely, that some phases will overlap. You may well (and probably should) find yourself starting construction on one part of the system while still writing specs for another; and more likely than not, you will implement the system in phases, or roll out parts of it to different constituencies, before testing – or even construction – is complete on other parts. All to the best, as our approach will allow you to stagger your milestones in such a way as to always be able to report some meaningful accomplishment (provided, of course, that it is actually successful!).
The next challenge is to align the lifecycles at the Process level. Comparing the Project Initiation phase with the System Requirements Definition phase, we see that while the Project Charter can be created before any of the System Development deliverables are produced, the same is not true for even the initial Scope, Schedule and Budget documents. First of all, those primary project parameters are sequentially dependent: you need at least a high-level schedule to prepare a budget estimate, and you need a good idea of the scope in order to create a schedule. Secondly, until the business requirements are nailed down, it is exceedingly difficult to come up with a sensible scope. Consequently, the Scope, Schedule and Budget deliverables must wait until at least Business Requirements are produced, and cannot be finalized (and included in the Initial Project Plan) until the Functional Specification is done. The rest of the Project Management deliverables in the Initiation phase, though, can proceed apace, while the project team defines Process and Data models and produces Functional Specifications.
A similar situation arises in aligning Planning and Design phases. Accurately defining technical architecture and system standards is imperative to successful system development, but does little to advance production of the final project scope, schedule and budget deliverables. Refining those documents can start at the time the system prototype is being developed, but it cannot be totally complete until the Technical Specifications (with all the attendant module specs and test plans) are signed off. On the other hand, elements of the Quality Management process, and certain components of the Project Plan (specifically those dealing with organizational impact and implementation/transition plans) will have a bearing on the Technical Specifications.
In aligning Project Execution with System Construction and Implementation, it is important to realize that while the System Development processes here are logically consecutive (you can't test something you haven't developed yet, and you shouldn't deploy something that hasn't been formally accepted), the Project Management processes in the Execution phase are concurrent, and apply equally to pretty much all the activities on the system development side.
Also, the deliverables on the Project Management side are all interim, “as of” deliverables, produced, refined, and reproduced with each development cycle: the schedule and budget are constantly updated with actuals; the change control, issues and acceptance logs are augmented as the triggering events occur. All the significant milestones for these phases will reflect System Development deliverables.
The Project Management lifecycle reasserts itself with the final, Closeout, phase. The system has been deployed and turned over to Production Support; what remains is the supremely important task of assessing project performance and determining which lessons learned should be avoided in future endeavors, and which best practices should be duplicated.
Identifying the Milestones
Having gained an understanding of the sequence in which both Project Management and System Development deliverables are produced (and how they are interdependent) we can now proceed with identifying the milestones that can be used to report project success in tandem with the corporate reporting cycle.
Project Charter is the first meaningful deliverable that can be identified as a reporting milestone. While it is not necessarily voluminous and does not generally take a significant effort to develop, it nevertheless represents agreement on the project's overall direction and approach among all project constituencies, and as such serves as a more or less formal “contract” for the project. Also, it can be used as a “quick hit” to generate positive momentum for the project.
As we have noted before, the project's initial Scope and associated Schedule and Budget documents cannot be developed until the System Requirements deliverables have been produced. Depending on the size of the system (and the associated effort it takes to discern functional requirements) the Business Requirements deliverable may be regarded as the next reportable milestone. Getting a sign-off on Functional Specifications, however, should be reported as a major accomplishment on any project.
While these System deliverables are developed, the Project Manager is busy identifying risks and quality standards, developing a Communications Plan, and defining main project parameters. While each of them is important to the project, once they are finalized following the completion of Functional Specifications, it may be advantageous to package them all together, and present them as a grand final deliverable for this phase – the Initial Project Plan.
The Project Management deliverables defined in Initiation are refined in Planning, and most of them cannot be finalized until the System Design deliverables are produced. The first tangible deliverable on the technical side (that can be understood by non-technical people) is the System Prototype. A successful Prototype is indeed an event worthy of highlighting on your manager's monthly report – it is the first time the business units – the Customer – got their hands on something that substantiates the great effort they expended detailing their requirements.
The Technical Specifications document is undeniably a technician's deliverable. Even when fully annotated in business English, in its full expanse it is impenetrable to the uninitiated. However, it represents a great deal of effort consumed, and is the blueprint for the remaining system development effort; it should definitely be regarded as a milestone.
It should in due course be followed by the Project Plan which includes not only the finalized versions of the Scope, Schedule and Budget but also all the other documents the Project Manager has been working on in this phase, such as Risk Management Plan, Quality Management Plan, Project Implementation and Transition Plan, Organizational Change Management Plan, etc. Acceptance of the Project Plan indicates the organization's commitment to complete the project.
As noted above, the Project Management processes in this phase are produced throughout the duration of the phase, change week to week, and are transient in nature. None of them can be counted as a milestone in its own right. It is on the System Development side where the rubber meets the road. The deliverables come fast and furious (well, we hope they do!). The individual modules accrete into sub-systems that are integration-tested and submitted for acceptance. Individual judgments should be made at that point as to how to choose the proper milestones. It is obvious that you can't report each module's construction as a milestone; it is equally obvious that you can't wait for the whole system to be deployed before coming out of the “black box”. A successful Integration Test of a sizable portion of the system (a logical sub-system) may meet the need; or perhaps you may decide to wait for that subsystem's formal Acceptance. In any case, it should be spaced well enough apart that you can report significant, understandable achievements in every corporate reporting cycle.
Completion of User Manuals and associated Training Materials should be identified as a milestone; it is a visible reminder of the system's impending arrival, and a great indication of your concern for your customer.
In Implementation, the moment everyone's waiting for is naturally System Deployment, which will again probably not come all at once, but be phased in over a period of time. Prior to that, however, for system development efforts that involve significant data conversion or acquisition, Data Validation may serve as an appropriate milestone. Finally, formal System Transition may be useful to mark the point where Execution formally ends, and the Closeout activities begin.
Project Closeout allows the organization an opportunity to capture and apply lessons learned on this project to all future projects; from the Project Management perspective, the importance of this phase is only eclipsed by the success of the system itself. It starts with an honest assessment of the project's performance, followed by identification of best practices and lessons learned. The Project Assessment report is the repository of the knowledge acquired the hard way, and is the vehicle for communicating that knowledge to the rest of the organization. Above all else, it highlights the value of the formal Project Management approach and its benefits to the organization.
By the time the final activities of project closeout come around, nobody cares about the project anymore, and boasting about successful archiving of project materials may be a bit anticlimactic.
So there you have it. By aligning the Project Management and the System Development lifecycles and deciding which deliverables can be used to periodically report project success to Project and Executive Sponsor management layers, we came up with a sequence of milestones that should generally coincide with the corporate reporting schedule, and provide meaningful updates of the project's progress.
“Your mileage may vary” – the specific circumstances of your project may dictate modifications of the milestone sequence we've discussed; but by applying the same criteria, and by understanding the interdependencies of Project Management and System Development deliverables, you should be able to come up with a list of milestones that accurately and positively portrays the progress of your project while highlighting the value of your project management contributions.
New York State Office for Technology. (2002) Management's guide to project success. Albany, NY: NYS OFT
New York State Office for Technology. (2003) New york state project management guidebook, Release 2. Albany, NY: NYS OFT
© 2004, Jonathan Blake
Originally Published as part of 2004 PMI Global Congress Proceedings – Anaheim, California