Integration of the project management life cycle (PMLC) and the systems development life cycle (SDLC) in accelerated project efforts
adapting project management best practices to unreasonable requests
T.A. Flynn, P.E., PMP
Currently, there are different approaches to managing projects that possess both a Business and Information Technology/Systems Development scope component. Regardless of who leads the project, Business PM Resource or IT PM Resource, a clear execution strategy must be matched or crafted to the rigors of the project’s expectations and objectives…especially in the case of accelerated objectives…and today, everything seems to be accelerated. This paper will delineate insights and lessons we have learned over the years consulting to, managing, and recovering complex projects with accelerated timelines both domestic and abroad. The paper will pay particular attention to the critical components of execution planning and project integration that have proven successful in many complex and “unreasonable” technical project efforts.
Accelerating the Accelerated
There aren’t many projects today that aren’t expected to achieve a quick-pace of deliverable execution. The predominance of end-date development prior to front end planning ensures that project execution will be accelerated to some extent. In the context of this paper and within our own consulting practice, we have a specific definition for the term accelerated project that goes beyond the need to merely move quickly. An accelerated project is one where the timeline is accelerated by more than 25% of that deemed reasonable by at least a sound OOM-ROM (order of magnitude of rough order of magnitude) estimate. Given that the most basic of projects contain some form of accelerated expectations, we are really accelerating the already accelerated. Some of the common industry terms used in conjunction with these types of projects are “concurrent engineering-design” and “fast track”. These terms seem to be more and more casually thrown around today as quick solutions to complex problems. To be effective solutions and to minimize the risk associated, a greater level of cognizance and understanding must be achieved regarding the inherent pressures and requirements of accelerated modes of delivery.
Inherent Pressures and Requirements
Once we have decided that accelerating the project is feasible (relative term as not all projects can be or should be accelerated), we must then be willing to face and realistically deal with the following inherent pressures and requirements.
- Although accelerated, we must still achieve the projects “major” scope targets and objectives. Scope growth and scope creep must then be limited by early “scope and design freeze”. Proper Up-Front planning is still required…we need to know where to focus our efforts early.
- Risk cognizance and diligence must be raised and maintained throughout the project
- Requires a very experienced project manager that is “battled tested”. As the project will move much faster than other efforts, the project manager will also require a higher level of authority to make decisions “on the fly” and the organization may not be practiced and/or comfortable with this requirement.
- Places stress on the communication and integration capabilities of the provider and customer organization and these cannot be ignored, over simplified by slogans or motivational speeches.
- Roles and responsibilities must be very clearly spelled out as a “slip” in deliverable development or miscue may cost us a major deliverable, milestone, or in the worst if cases; the entire project.
- In large systems projects, which are the focus of this paper, we must be very clear about which of the many life cycles within the project confines is actually organizing and integrating overall execution.
- Traditional methods and Best Practices must be adapted to the pace and risk level of the project.
Dueling Life Cycles: Whose Project Is It Anyway?
In many of the complex systems development projects we are involved with, the project manager resides in the Information Systems Division (ISD) or Information Technology (IT) areas rather than in the business unit requesting the system or technology. This is not an issue as long as we remember that the project has many “life cycles” to integrate and that the SDLC is merely one of the project’s life cycles that require integration. We have seen many organizations where the dominance of ISD/IT project managers leads to a “technology project” mindset. By “technology project mindset”, I mean that the organization is so technology focused in its approach that many times it tends to minimize the business’s role in the project…and they always seem to be amazed when the system receives low to no acclaim upon delivery! Two general filters we use to assist ISD/IT organizations in realizing business vs. technology project are:
- If you, the ISD/IT unit, are your own customer for the subject project, IE: server upgrades, security upgrades, etc., then it is certainly a technology project.
- If the customer is a business unit with specific business demands that drive the development of the subject system, it is much wiser to consider it a business project and keep the business stakeholders as close to the project as practical.
As stated above, it is most critical to realize that there are many “life cycles” or sub-life cycles within a project with the Project Management Life Cycle (PMLC) serving as the point of integration for them all (Exhibit 1).
Exhibit 1: Integrating Various Life Cycle Concerns
As depicted above, the PMLC is the main point of integration for the project’s various life cycle deliverables. Managing the project “swim lanes” is the key role and responsibility of the project manager. When this level of life cycle cognizance is present in the project, integration, communication and execution are made much easier for all involved.
Adapting Traditional Approaches
The inherent complexities and constraints of accelerated projects require us to adapt and integrate multiple and traditional project management and system design methods. The table below (Exhibit 2) lists a few of the traditional SDLC approaches ranging from Linear to Extreme categories and their respective practices-methods.
Exhibit 2: Traditional SDLC Approaches
Exhibit 3 below illustrates the range of scope-technical cognizance (certain to uncertain) and the general application of SDLC categories across the range of certainty - uncertainty.
Exhibit 3: SDLC Approaches and the Range of Scope-Technical Cognizance
Establishing life cycle cognizance first and adapting development models for technical scope deliverables second has yielded elevated results in our project assignments. This proper “structuring” of the project, IE: life cycle cognizance, appears to be in line with the findings of John McManus (2003) where he posits that managerial issues account for 65% of project failures and technical issues for 35% of project failures as listed below.
|Managerial Issues (65%)||Technical Issues (35%)|
| || |
Within the context of complex and accelerated projects, we have found that the strict application of one model is usually not very useful. Depending on the certainty or uncertainty of the technical deliverables, we have been very successful matching, scaling, and adapting the practices as required by the demands and constraints of the project. Exhibit 4 depicts a recent application model of this process of best practice adaptation.
Exhibit 4: Adaptation and Integration of SDLC Approaches with the PMLC
As the graphic model depicts, business requirements that caused unknown technical requirements were channeled through a modified and cyclical extreme approach until these were exhausted. These technical requirements (the originally known and the recently known) were channeled to and through a modified and cyclical Adaptive Project Framework approach until the development of the technical deliverables were exhausted. In the case of “stubborn” technical deliverables or “first time” technology issues, a “carry” estimate (with medium to high contingency allowance) was utilized during the planning phase to create “Planning Package” budget and to allow the “known” project deliverables (work packages) to proceed to execution. Simultaneously with the beginning of the Execution Phase, a rigorous “Rolling Wave Planning” process was instituted to transform the Planning Packages to Work Packages. Once this transformation was achieved the revised estimate was compared to the “carry” estimate and the contingency adjusted accordingly.
This model requires a great deal of discipline and a willingness (and competency) to move forward and backwards amidst known and unknown scope areas - deliverables. Documentation is also a key element here as we could easily loose the “thread” (current critical priorities) of the project given the combination of speed, risk, and iteration. An important factor to success in the transformation of planning packages to work packages and forward integration to execution is the use of “cut off decisions”. These decisions are bounded with metrics and dates in order to assess if the development of required deliverable or function can actually be accomplished by specific milestones and without jeopardizing major scope elements of the project. These decisions are jointly made between Business and IT/ISD Steering Team members which levels the accountability for these decisions properly across the organizational strata.
Adapting Specific Project Management Practices
Currently, we have elaborated on the SDLC side of the equation, now let’s take a look at some critical key project management elements and their application and adaptation in the successful accelerated project.
- Must be “managed” (intentional not adhoc), timely, and accessible to all – “project collaboration software” and “co-location” of project teams are helpful best practices here…
- The Project Manager will be doing a lot of WAM-ing…must keep the pulse on the integration of deliverables from the various life cycle contributors
- Project Manager is the main point of contact from and to the business customer and Steering Team so mixed messages are avoided
- PM must be alleviated from the “admin-grind” and removed from the technical details…we do so by creating the following team structures…
- There will be many situations that will need to be “solved” above the project level…must have the right mix of “clout” and “availability” for this practice-structure to be effective…must be agile and able to make quick decisions
- A proxy to the project core team will be required if major “players” can not meet the availability demands.
Project Core Team
- Project Manager, Customer (Business) Representative, Major Functional-Technical Leads are key (internal-external organizations) in order to keep the project manager out of the “fray” and to ensure deliverable production schedules are maintained amongst the various functional contributors.
- Master Scheduler and Control resources (may be one in the same)…constantly watching baseline performance for critical variance.
- Plan for the “long haul”, IE: ensure that the right folks are on the team…Benchmark data shows us that any key member replaced after 15-20% progress extends the schedule a minimum of 15%
- Roles and responsibilities must be clearly documented for accountability.
- Communication protocols clearly defined within the core team.
- Begins early by managing the business objectives – requirements into a rigid timeline.
- Prioritization schemas established…early “Scope Freeze” is mandatory in order to meet procurement lead times, facilitate Cut Off Decisions, and “hold” accelerated end dates.
- Once portions of the scope are frozen, the “discovery” work (where required) establishes the technical requirements and deliverables (known and unknown)
- The technical leads are responsible for scope-configuration control and management of their technical scope packages
- There must be a clear delineation between Work Packages and Planning Packages within the overall scope.
- All change requests are documented and must follow a formal approval process (limit feature creep).
- This really is the Project Managers and Functional -Technical Leads key function…the business objectives and associated scope “frozen” early will help restrict the risks to technical, integration and execution areas.
- The Schedule and Control resources watch the timeline assisted by the Functional-Technical Leads whom are accountable for the execution of their respective “scope and planning packages”
- Schedules will be a mix of Critical Path and Critical Chain…depending on the degree of “cognizance” we have in the deliverables and the status of major deliverables at any given time. Need to be rigorous, yet fluid.
- The Integrated Master Schedule is of great importance and must be maintained…only way the PM can see the Integration effects of late “starts & finishes”. This data will be a direct input to the aforementioned “Cut Off Decisions”.
Meetings, Reviews and Control Issues
- Project Level Meetings
- Alignment Sessions at major phases, junctures, and milestones.
- Daily musters when and where required (quick and decisive direction setting).
- Formal Signoff-Concurrence review to freeze the business objectives-scope.
- At major technical milestones (performance and integration checks).
- Prior to major project integration milestones (across functional groups).
- Control Issues
- Execution planning elements must “put the edges in” (define what’s in and out).
- Project Manager cannot be the “chief cook and bottle washer”…can’t do it all and ensure proper integration and customer management at the same time.
- Project Manager and Project Leads must be very clear as to their change management and performance thresholds.
- Metrics must be established, monitored, and acted upon rigorously.
- Because of the duration “compression”, normal mistakes will be multiplied at greater levels of magnitude.
- Many project mistakes are the result of inaccurate communication and mixed messages…this is why the Project Manager must be supported as the project’s “one voice”
- The Project Manager’s partnership with the steering committee resources (stakeholders) and the Project Leads is key to success. In turn, the Project’s Leads assume like-type leadership roles within their own scope-functional areas.
- Project Manager must be able to deal with chaos, crisis, conflict, and ambiguity (on the fly). A very senior mix of leadership competencies are required and certainly, a sense of humor!
Successful management of accelerated projects requires:
- The combination of adaptive approaches based on the project’s demands-characteristics
- A conscious decision to accelerate based on business impact and an understanding of the project ramifications
- Heightened levels of project support and partnership
- An early determination of business objectives…can’t figure it out as you go!
- Increased spending levels due to increased levels of risk…which drive different team and control mechanism structures-functions
Committing to a steady diet of accelerated projects is not advisable as resource burn-out is much higher with these efforts and their success rates are only improved by adaptation of best practices; certainly not guaranteed.
Highsmith III, J.A. (2000) Adaptive Software Development: A Collaborating Approach to Managing Complex Systems. New York, NY: Dorsett House.
Keller E. (2004) Technology Paradise Lost, Greenwich, CT, Manning Publications.
McManus, J. (2003) Risk Management in Software Projects, Burlington, MA: Elsevier Publishing.
McConnell, S. (1998) Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.
Palmer, S. R. & Felsing, J. M. (2000). A Practical Guide to Feature Driven Development. Upper Saddle River, NJ: Prentice Hall PTR.
Robertson, S. & Robertson, J. (1999). Mastering the Requirements Process. Reading, MA: Addison Wesley.
Schwaber, K. & Beedle, M. (2001), Agile Software Development with SCRUM. Upper Saddle River, NJ: Prentice Hall.
Standish Group (n.d.) Standish Chaos Reports: IT Project Retrieved from http://www.standishgroup.com/sample_research/index.php
Stapleton, J. (1997). DSDM: Dynamic Systems Development Method. Reading, MA: Addison Wesley.
Wysocki R. K. (2005). Adaptive Project Framework: A Common Sense Approach to Managing Complex Projects. Worcester, MA.
Wysocki R. K.& Young, J. (1990) Information Systems Management - Practices in Action: A Collection of Management Situations, Hoboken, NJ, John Wiley and Sons, Inc.
Wysocki R. K.& McGary, R. (2003) Effective PM: Traditional, Adaptive, and Extreme, Hoboken, NJ, John Wiley and Sons, Inc., 2003.
© 2007 T.A. Flynn – Advanced Management Services, Inc.
Originally published as a part of 2007 PMI Global Congress Proceedings – Atlanta, GA, USA
Presents the latest thinking regarding good and accepted practices in the area of scheduling for a project.