The steps of the project lifecycle may not necessarily run consecutively. Often the steps will overlap and run concurrently for some period of time.
Editor's Note: This article is excerpted from chapter 2 of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch.
Part 1, Project Lifecycle, is available here.
For example, if the planning step is scheduled to last for ten weeks and the project will be a three-phase implementation, you may want to get your development team working on the designs for phase one before you have completed the planning for phases two and three.
If you are inflexible on overlapping the steps, you may find that you are wasting a lot of development time while your development team sits around twiddling their thumbs waiting for something to do when you are in eight hours of planning meetings each day! To maximize the effectiveness and efficiency of your team, you should always be looking for ways to keep everyone working at full capacity and minimizing project downtime.
Some features will need more design time than others. It will depend on the size of the feature. You should not stop your team members from moving onto the development step for features that have completed designs because you have other team members who are not finished with that step yet. The same can be said for moving from development to integration.
You will find at times that some of your team members are on a different step in the process than the others. However, you should still have timelines for each step. You should document the start and finish dates for each step even though you know you will have a few exceptions to those hard dates.
You may be managing, or working in some capacity, on more than one project at a time, and this will add to the differing number of lifecycle steps that you are required to manage at any one time. In order for the company to be consistently working on projects and keeping all the employees busy, they will very likely be planning the next project while you are still implementing the current one. This planning is also likely to require some of your time. If your project timelines are not too long, you may find that you are managing the post-deployment step of your last project while at the same time managing the deployment step of your current project and the planning step of your future project! It is all about juggling your time and setting priorities. It can be challenging, but it is also a lot of fun, and it certainly does not allow you time to get bored!
In longer-term projects, it is often a cause for celebration to be moving from one lifecycle step to the next. Just when you thought you had taken all you could stomach of day-long planning meetings, you move into the design phase. Then again, just when you are feeling a bit less challenged by development, when everything is running so smoothly, you switch to the integration phase and find lots of issues that require your troubleshooting skills. Many teams celebrate meeting the milestones that move them to the next step of the project lifecycle. It is easy to track progress using the lifecycle wheel, and though you know that it starts all over again as soon as you finish, it is still fun to see yourselves getting closer to the end goal.
Project Stage Gates
A stage gate, also referred to as a phase gate, approach to project management formalizes the various approvals that occur throughout the project into a standardized approval framework. The idea is that the project stops at each stage gate and cannot proceed to the next stage until the approval has been completed. The methodology in this book can be used as part of a stage gate process. The table below shows the project lifecycle phases and the corresponding stage gates. These gates are not set in stone. You can add or remove stage gates based on the specific process used at your organization for approving projects and project funding. The approvers listed are not necessarily all required. One or more would be usual.
You may need to add additional approvers based on your organization’s specific stage gate approval process. After the planning phase is complete, it is assumed that the sponsor and any senior managers who will remain involved in the project will become part of the steering committee and therefore are not listed separately.
Project Lifecycle Phase |
Stage Gate |
Stage Gate Approvals |
Approvers |
Planning |
Project Concept |
Project Concept approved Funding and resources approved to create Project Proposal |
Client Sponsor Senior Management (funding) Product Management |
Project Proposal |
Project Proposal approved Funding and resources approved to create Charter, Marketing Requirements Document (MRD), and Budget |
Client Sponsor Senior Management (funding) Product Management |
|
Project Approval |
Project Charter approved MRD approved Budget approved Project funding and resources approved to build product |
Client Senior Management (funding) Steering Committee Sponsor Product Management |
|
Design |
Design |
Technical Designs approved Technical Specifications and Task Lists approved Project Schedule finalized Any schedule or budget changes approved |
Steering Committee Technical Lead/System Architect Project Management Office (PMO) Project Manager |
Development |
Development Complete |
All development tasks complete Unit testing performed Schedule updated Technical Designs and Specifications updated QA Test plans created Any schedule or budget changes approved |
Steering Committee Technical Lead/System Architect PMO Project Manager Quality Assurance Manager |
Integration |
Code/Product Complete |
All software, hardware and networking integrated/merged to create final product Quality Assurance testing complete Product optimization and bug- fixing complete Deployment, Operations and Training Plans approved Service Level Agreement approved Any schedule or budget changes approved |
Steering Committee Technical Lead/System Architect PMO Project Manager Quality Assurance Manager |
Deployment |
Deployment |
Deployment and Training Plans implemented Deployment or handoff of product completed Client acceptance agreement signed Any budget changes approved |
Steering Committee PMO Project Manager Client Operations Manager Training Manager Sales Manager |
Post- Deployment |
Project Closure |
Operational support plan implemented Lessons Learned conducted and Tactical Plans created Point Release and Ongoing Training Plans approved Project Closure approved |
Steering Committee PMO Project Manager Client Quality Assurance Manager Operations Manager Training Manager Sales Manager |
Sarbanes-Oxley Act (SOX)
During the 1990s, numerous corporate accounting scandals led to the loss of billions of dollars of investors’ money. In response to these scandals, in 2002 the United States government introduced the Sarbanes-Oxley Act, affectionately known as SOX, but also referred to as SarBox or SOA. It is named after Senator Paul Sarbanes and Representative Michael Oxley, who were the main architects of the act. The SOX Act introduced new regulatory requirements for publicly traded companies. The regulations apply mostly to accounting and IT practices. It is beyond the scope of this book to include in-depth details of SOX requirements. Suffice it to say that projects considered to be “financially significant” may come under the umbrella of the SOX Act. This means that the person responsible for the outcome of the project, the project manager, has certain legal responsibilities to meet SOX requirements. The legal department or SOX committee at your company will determine to which projects SOX applies. Some organizations, particularly those in the banking and finance industries, err on the side of caution and require that all projects be developed in compliance with SOX regulations.
You will not be able to meet SOX requirements for IT projects unless you are consistently using a structured methodology and applying good project management practices. At a very high level, SOX requires creation and retention of project records. This includes all project-related documents, specifications, correspondence, and decision and analysis documentation. SOX also requires that applications or products developed under SOX compliance have appropriate security and encryption in place. The security and encryption requirements may or may not be applicable to your project(s). If you are assigned to projects that require SOX compliance, I recommend that you learn more about the SOX Act and consult with your PMO, SOX, and/or legal departments to ensure that you understand exactly what is required from you and what individual responsibilities you have under the law.
It is unlikely that your organization would expect you to have an in-depth understanding of SOX. It will certainly work in your favor if you can demonstrate that you know what SOX is and why it is needed. What you have just read in this section will not make you an expert, but it will enable you to show that you have a basic understanding. This basic understanding will also ensure that when someone asks for your “SOX checklist,” you don’t start writing out your list, “3 pairs of white ankle socks, 4 pairs of wool hiking socks, 2 pairs of formal black socks, 1 pair of running compression socks.”
The website http://www.sox-online.com explains the Sarbanes-Oxley Act in relatively easy-to-understand terms. Certainly it will be more understandable than reading the Sarbanes-Oxley Act itself!
Next time: Project Management and Quality Management Standards. Can't wait? Pick up your own copy of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch - available and on sale at the MC Press Bookstore today!
LATEST COMMENTS
MC Press Online