Read the previous parts of this 3 part article by following the links below
Depending on the maturity of the organization you are working with, you may have a PMLC already defined, or they may be using a software development life cycle (SDLC). The PMLC tells you what things you need to do and when you need to do them as does the SDLC. What I am going to try to do is explain what I believe is an optimal PMLC, and step through each of the phases and stages while providing valuable lessons learned and things to remember. If you do not have a PMLC defined in your organization this may be a good opportunity to start looking at the organization’s environment and helping them to define one.
First let us talk phases and stages. While working at an organization together, a peer (we will call her Donna) and I both shared the same beliefs as it came to the PMLC, with a few disagreements here and there. When you consider phases and you look across all the different methodologies one thing is common between them. You have a phase where everything begins (Initiation), a phase where tasks, resources and time may be figured out (Planning), and a phase where the work is done (Execution). Depending on the methodology or principle that is being followed it may also have a closing phase. Where some of the differences may come is what stages occur in the phases. I consider the below a format that is beneficial to any organization.
If the organization you work with is also involved in implementing a lean process, you can also factor in the left and right sides of the A3. This is easily shown in the diagram below.
Either of these are very simply layouts, but that is where even more of the organizational environment comes into play as to what processes and artifacts are required within the stages. By taking the above table and expanding it a little bit further, you can also incorporate items as they relate to SOP 98 – 1, otherwise known as some of the standards behind internal labor capitalization.
The above table is not meant to be all-inclusive as it relates to SOP 98-1, as there can be strict guidelines that deal with specific areas. Many of the organizations that I have worked in had their PMLC detailed out to processes and artifacts, and I have also played the role of creating them.
Can There Be Different PMLCs in the Same Organization?
Sometimes an organization may have a tiered PMLC set up…like a T-shirt sizing methodology and based on certain criteria the processes and artifacts may be required or optional, and at times the artifacts themselves may differ. It is common to see this as the rigor behind more complex and costly projects and is often required more than a smaller initiative. These criteria could be based on local versus international, total cost, capital cost, whether there is hardware and software purchases required, if it is a multi-year effort and even whether third parties are involved.
Each organization needs to determine whether one or multiple PMLCs are required. I have worked in one organization where there were primarily two PMLCs. The two PMLCs that were used were to differentiate from a full project or what was considered operational development. If it was determined to be a full project, the size did not matter as all the discipline was the same. The PMLC is there as a guide to help a project manager, the project team, and the business all understand the tasks and activities that are to be taken to complete the project successfully.
You may find a PMLC is very strict and specific for larger projects, where with smaller initiatives the PMLC is often very truncated. This does not mean that artifacts or processes should not be followed especially if your project requires it to be done. In other words, just because it tells you that you do not have to do it, does not mean that you should not do it.
If you were to do a search on the Internet for examples of project management lifecycles you would see Excel spreadsheets, PowerPoint’s, hierarchal diagrams, circular references, as well as anything and everything you could imagine. Make sure that the one you follow is the one that has been used within your organization.
Become intimately familiar with your organization’s PMLC(s). Learn their processes and quickly identify items that you have not previously had experience in.
Make sure you make your entire project team and business partners aware of the PMLC process. This will only help to ensure their participation and support and help them understand why certain things are occurring on the project. This can also give them a head start, a kind of road map, of the journey that the project takes. You may find yourself taking on the role of an educator and helping them understand what the PMLC process is within your organization.
Use a printed copy of the organization’s PMLC like a checklist to ensure you complete everything that may be required by them. Always remember that even if something is not required does not mean it should not be done for your project…you must be able to identify those items and do what is right for the project and the organization.
Why is a PMLC even needed? I Know What I am Doing!
We cannot tell you how many times we have heard the famous words of “I know what I’m doing” only for it to quickly be proven that they did not know what they were doing. Remember what we just said, you must understand that every organization does not do things the same way. You need a PMLC to help you understand how they expect the project to run, what their expectations are as it relates to documentation, and what their standards are as it relates to phases and stages.
At one organization I worked for, one of my primary responsibilities was ensuring project managers around the world understood the global PMLC that we had in place, as well as training them on the applications that we used for project management. The PMs and PGMs that succeeded were those that were not afraid to ask questions, attended the training, listened and applied what they had learned. Those that did not…well, they did not fair too well.
As different organizations have different meanings for the basic term project manager, as one PM I worked with found out when he was hired on as a PM, the organization that he came from had completely different expectations. He learned he had primarily served as a technical lead and that there was a lot more expected of a PM that did end-to-end project management. At first, he had fears that he would fail but he was willing to learn, and learn he did. He quickly moved on to be a great PM with a specialization in infrastructure. Yes, you can have a specialty field in project management. I would not expect an IT PM to be able to be a PM that is in the construction field. Although a lot of the framework for project management is the same, there are great differences. Same within the medical industry versus a simply software company. The rigor put behind projects that are relative to life-saving devices is much greater than a database that supplies data for analytics. You must understand the process itself.
As my background is primarily in the IT, retail and logistics industry, and the connections I have with PMs across varying fields, I can take the experiences I have had, and the unbelievable things I have seen and easily be able to apply them across an IT industry. If you are a junior PM just starting on the project management path, do not be afraid to ask questions and learn everything that you can learn from the PMs that are already working within the organization. One of the quickest ways to fail within a new organization is to believe that the way you have done it in the past is the way that they are going to do it there.
You do not know everything and you cannot do everything alone. Every company does not operate the same. Get familiar with the expectations of the organization.
Just because one organization gives you the title of PM, that does not mean that you function as a PM. Be sure you understand what the organization expects from there PMs. Often implementation leads are called project managers…learn to know and understand the difference.
Just because you did great in an IT industry does not mean you can easily transition to a medical or construction industry. Even though the framework is the same you still need to have a basic understanding of the process, resources, and materials behind the projects.
Do not be afraid to put extra rigor behind your project if you feel it is needed.
It is important to remember an organization should not be made to fit within a PMLC. What should happen, is a PMLC should be built to fit within and for the organization. If you see challenges or opportunities with the existing PMLC do not be afraid to bring forward any ideas for improvement.
Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.
|Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE|
|We hope you will consider joining our Facebook Community as well. Click on the image to your left to visit and join, or you can CLICK HERE|
Reading this article qualifies you to submit a request for PDU’s from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU’s
For more information on registering your PDU’s with PMI – CLICK HERE
At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE
Over 20 years project management experience with a passion for helping organizations grow their PMO, their project managers, and their teams. My passion has taken me to the pursuit of a Doctor of Education, as I enjoy seeing the proverbial light bulb come on. I am a believer in continuous growth and improvement, and believe that an organizations culture and environment is what drives the growth of PMOs and all areas, and not the other way around.