A product is not by definition temporary, but if it’s decommissioned/retired, then it’s over. A product exists to solve an ongoing business need or want. If there is no need nor any want, then there is likely no product (worth sustaining).
A project is a temporary endeavor undertaken to create a unique product, service, or result. I would take it further and say this is undertaken taking into account one or more business cases.
The software development life cycle (SDLC) is often part of product development generally (where there’s software to be made as part of a product life cycle) and the project life cycle (especially planning through the end of execution, which includes monitoring & controlling).
The SDLC is a process for delivering software and is commonly known as consisting of the following phases (or some associated variants):
Analysis – understand what should be made to achieve the relevant goals (business need or want)
Design – determine the way in which the implementation should be done so that it is sustainable
Implementation – make it
Testing – make sure it works as expected
Deployment – get it out to the relevant environment
Maintenance – keep it running and resilient
The development methodology selected will determine when any of the above phases of the SDLC are active. The ones I have worked with are waterfall and a few agile variants (Scrum, Kanban, and XP). I will not go into detail on these methodologies in this post.
How are products, projects, and software development related?
As my role has often been a mixture of project manager and product manager, I have seen how my involvement in the product vision ends up affecting the delivery of project outcomes resulting in the desired product.
For product management, I refer to the phases referenced in the ProdBOK® maintained by the Association of International Product Marketing and Management (AIPMM):
Conceive – generate and prioritize ideas prior to putting in product planning efforts
Plan – define the product more clearly by covering experience design and other market validation to ensure this product is worth developing
Develop – build the product according to the plan with deliverables and beta preparation
Qualify – conduct beta testing through select external users to refine the product and prepare for the launch with relevant marketing and sales training
Launch – get it out there with the appropriate messaging and acquire users
Deliver – scale the product to maximize opportunities and increase sales
Retire – take steps to end support for the product including preparation of any necessary license terminations or documentation on migration to other products
For project management, I refer to the domains referenced in the PMBOK® Guide maintained by the Project Management Institute (PMI):
Initiate – get buy-in and approval to progress
Plan – detailed analysis of the scope, schedule, cost, and other variables that will affect the final outcome of the project
Execute – deliver the outcome according to the plan
Monitor & Control – take relevant steps to ensure execution is going according to plan
Close – wrap up once the project outcome has been achieved (or some other event happens that ends the project)
From my experience the way this would work conceptually (taking into account what I said about the development methodology above) is as follows:
I have seen that according to the Optimal Product Process™ that “Launch” and “Deliver” (or Maximize) are not traditionally associated with the SDLC, but I don’t believe there is a hard rule suggesting that they do not apply in those two product life cycle phases. There are numerous professional perspectives on how the overlap works, and all of them are valid in different contexts.
In my product perspective, which is focused on non-stop momentum and sustained value delivered to customers, there should be continuous software delivery without unreasonable stoppage until the product is set to be decommissioned or retire. That includes continuous delivery during the Launch and Deliver phases where necessary.
Additionally, regarding “Deployment” and “Maintenance” in the SDLC, it’s entirely possible that there is not much to consider in a “pre-production” (Pre-Launch) phase of the product, but I believe they still apply whether we are in pre-prod or prod due to how the development operations may be set up.
To recap, when “doing the work” to get the product made, many projects can take place to build and improve the product throughout its life. If we are talking about software and in an agile development context, then the phases of the SDLC will take place throughout this building and improvement of the product typically in scope of one or more projects. The level of formality and process strictness applied depends on the standards applied by the relevant product, project, and delivery managers. Business analysts will often have a role to play in all three distinct life cycles to bridge the relationship between the three.
There is no one-size-fits-all approach in managing desired outcomes for a product or project, though I am generally a proponent of applying lean practices to focus on results over process.
The difference is clearer, so how does the SDLC work?
I will cover more about the SDLC and the associated development methodologies in another post.
In several projects, I have acted as the supporting product manager to a key product manager usually when the key product manager’s main contribution is a very high-level concept of what they would like built. In effect, such a vision is so high-level that there is no way to execute on the vision at all without properly describing and breaking down that vision into understandable parts, including defining the outcomes desired. I was in effect a technical product manager in that I could transform the idea into a technology solution, and the person I was reporting to or was obligated to deliver results to was in effect a client or sponsor that was not expected to understand how to execute on their vision. I was the person “on the ground”. Different product managers may have different visions on their level of contribution required, so there is no single rule on how product management should work and how the project manager may take on any product-related responsibilities.
As a person, I am often among the stars, but when I am working on a project, I stay grounded because I understand that execution requires understanding the stars while creating traceability back to the earth. That is what I have done for my clients. The further out they are, the more work I have done either on my own or with business analysts to define and break down what they want. It is critical to be able to work with a vision in a structured manner to manage scope.
Leader of the People: an anecdote
Before they can manage expectations, the PM must first be able to understand the people they manage as well as the people they may interact with outside of the project team. By understanding the behaviors and motivations of each stakeholder (whether internal or external), the PM can determine how to utilize project team members and interact with senior stakeholders. A part of empathy that I did not experience until setting up my own business was what drove the people that I hired.
Before I dove into the PMBOK®, I didn’t need to know these technical terms for being a relatable and empathetic human being, but I will admit it is helping me to structure my thoughts better. I learned through hiring and firing how to care about people before caring about my own small business, and it was a costly yet very rewarding exercise.
Getting the balance between management and leadership techniques was not a cakewalk for me in my initial experiences as I lacked structure. I used both techniques but did not know when to optimize them. For example, there were times when I would focus on maintaining the status quo to get the job done without considering how this would prevent my team from developing. I lost some people this way. There were other times when I would focus on R&D that would help projects long-term, but this created a risk leading to slower delivery.
All of the moving parts at the people level are following some sort of expected process regardless of whether it is the optimal one for achieving delivery. This is a major reason why PMs monitor and control the project’s activities, firstly to ensure nothing is occurring that would contradict another stakeholder’s expectations, but also to ensure that what was expected is refreshed, adapted, and communicated as needed.
Managing expectations is like managing promises. If I make a promise, I should keep it. So if I communicate information that gives a senior stakeholder an expectation about delivering a certain set of scope on time, then I should have checked with the delivery team beforehand that they can meet that expectation. Once the senior stakeholder has that expectation, it’s my job to manage daily activities with the team so that their expectations are continually managed to meet the senior stakeholder’s expectations.
In an agile execution approach, the work might be carried out in iterations. If the team runs into a roadblock and cannot deliver what they expected, I will need to have planned for that risk in advance, and I should have communicated to the senior stakeholder that such a roadblock could have happened. Whether I’ve done that will usually depend on whether I could have known about that risk (either due to my experience or if it was a truly unique and improbable situation in the circumstances).
Understanding the culture of an organization enables a PM to know how politics and power can be used to achieve outcomes. There are several forms of power referenced in the Guide, but I will go over the ones that I have observed or related to more often than the others:
Positional – determined in relation to someone’s formal position, indicating a level of authority
if a VP has input to provide about a project’s status, and they have the authority to affect what happens next on the project, it’s important for the PM to recognize when others have this power to be able to exert their influence onto an authority when needed to achieve goals
at the same time, within a project team, the PM can refer to their authority when suggesting that certain team members should execute certain tasks
Situational – when power is acquired due to a unique incident
if there is a production incident, the PM might have the authority to require operational engineers (system administrators or DevOps in the software application context) to start or stop certain systems
where the PM lacks this power, they could exert their influence onto a senior stakeholder such as a VP to make certain decisions; this is important especially when the PM has more technical knowledge (and therefore has more Expert power) than the VP in the circumstances
Guilt-based – when others are led to believe they have an obligation or a duty to execute
“we’re running out of time, we’re going to miss the deadline” – this is a mixture of power being utilized here, but the PM may have to apply Persuasion, Pressure, and possibly Coercion to help push the delivery of a task, but at what cost?
likewise, if a VP reminds the PM that they signed up for satisfying the customer’s business needs at all costs, it may signal a need that vacation should not be taken if the PM is unable to delegate their tasks
Acting with Integrity
Although there are times on projects when it is important to exercise influence and power, I have found it equally if not more important to act with integrity – never to compromise the trust the stakeholders have in me, and if I make any promises, to keep them unless an exceptional circumstance arises that makes it impossible to keep the promise.
I weigh the upside and downside of “letting things fail”. While it is important to delegate ownership to motivated leaders or to take excess work from a higher-up, I make sure to manage risk first and foremost. If for any reason I have knowledge about an area a higher-up should have had, but they acted upon not having that knowledge in a way that could trickle down to the project level, I will capture it regardless of whether it was delegated to me, adapt it to suit our project (if possible), and push it back into the process. The same goes for subordinates – if there is an overflow, then I determine what the cost of failure is, and I’ll lend a hand to keep things afloat if needed. To me, part of integrity includes not compromising others’ reputations, so this can take a lot of work, but I believe it’s part of good leadership.
If risks are managed properly, the PM can maintain their and others’ integrity by keeping processes smooth without carrying out any unexpected actions. Letting things fail is an option only if it’s easy to pick things back up without causing unnecessary strain. If it’s the only option available to bring a project back to sustainability, then I would vote for it.
Keeping Eyes on the Prize
Integration Management ensures all of the gears of the project management machine are running, and while a good PM will keep them running, their focus should be on utilizing a few skills that are not in the Guide’s standard, but are in my own standard:
The good news is, the Guide covers the need for continuous prioritization, being attentive to the project’s key constraints, being flexible, and being able to filter out key details from various types of artifacts and communication. For me, it requires using those three skills I called out in order to be effective at achieving these needs.
By keeping priorities up to date with a focus on accounting for the project’s critical success factors, I can optimize all of my activities and that of my team members towards getting the prize.
Questions that might pop up: technical project management, PM expectations
Which project element is least relevant to technical project management skills?
A. Budget B. Schedule C. Sponsorship D. Risk
Recall earlier that I wrote about competing interests and objectives. One of those answers is not equivalent to a Knowledge Area, and one of them is just closely related to an existing Knowledge Area. I think that is a good enough hint.
Which statement is least accurate? Project managers should be able to:
A. Apply strategy towards maximizing the project’s business value B. Explain the project’s strategy, mission, goals, products, competition, etc. C. Be aware of relationships with other people to get things done D. Take on responsibilities of unavailable team members during an incident
For other mock questions, read more posts from this tag. To learn more about my stories and my experiences as a project manager, get in touch. I have scratched only the surface in this post (and in the previous one).
Outside of the five domains, the PM may be involved in pre-sales involving business analysts, experience designers, and architects in addition to post-delivery support or other strategy tied to delivering projects. As another example, a PMO may have project managers that are involved in reviewing and providing consulting for different projects in the organization at various stages, and they could also be involved in assessing the organization in general to enhance its performance. It depends on the organization and the value a PM can provide outside of a five-domains project setting.
Who is not the project manager?
It must have been a discrete math course I took in college that helped me better understand the value of this concept, but we can know what “A” is by knowing what “not A” is. There can be other managers within the organization, and understanding them might help to understand a project manager a bit better. One often referred to in PMP® training materials is the functional manager (FM). The FM manages a business unit. They may have individuals within business units that are lent out to projects and could have some budgetary discretion that impacts projects, but in that specific role, they are not known for managing projects. Then there might be an operations manager. If a project is temporary, an operation is intended to be ongoing. Operations managers ensure that business operations run smoothly – it might be that the project manager has been responsible for the creation of a product that is then used and possibly maintained by that operations manager.
In one project, I was the project manager for a product-service used by hundreds of external customers. I say product-service because while the customers used a web interface for placing product orders, that product had to be put together in the form of an operations team gathering internally and externally sourced data, packaging that data into reports, and finally delivering them to the customer. That operations team would be run by an operations manager, but I was the project manager involved in improving that software. I interacted with various other managers as well, including the software’s product manager and sales managers.
I would also attend meetings with higher-ups who were in effect different senior functional managers that had oversight over the project manager, operations manager, and product manager, respectively. The person overseeing me was a director of project management, the operations manager a director of operations management, and so on. That was good to know, and it made life easier understanding what each person’s responsibility was, and where I fit into the picture.
The master supervisor and coordinator within the project
The project manager is involved in the management or execution of all of the project management processes depending on the stage of the project. Overall, they are delivering the project according to the agreed scope, schedule, and cost (alongside the other knowledge area components) with the aim of meeting the stakeholders’ needs according to critical success factors. They may be supported by various project coordinators along the way, depending on the size of the project. These coordinators will help to execute various aspects of the overall project’s processes, where the PM will oversee and ensure that all of these moving parts are working smoothly. As will be covered in the Initiation stage of the project, project managers Develop the Project Charter and Identify Stakeholders, though they may do this in assistance with other team members such as business analysts.
Juggling the various people, processes, and technology involves balancing a diverse set of competing interests, and this means managing the expectations of many different individuals. I wouldn’t want to trip up while performing my act, but a leader knows that when working within scarcity, priorities must be set. They might have to set down one of their juggling props during parts of the act to deliver a standout performance. Once priorities are set, the PM should manage every stakeholder’s expectations as to what those priorities are and minimize any risks or conflicts. More than ever, this post I wrote in 2013 makes more sense – although we’re still figuring out how to achieve global consensus, it is more possible at local levels, or in this case, the project level. A well-managed project can have the appropriate accountability, governance, and transparency to achieve consensus. Before I go on a tangent and talk about democracy (which I do enjoy discussing!), let’s get back to juggling.
As the master coordinator, the PM must be an excellent communicator making use of their soft skills to ensure the project’s goals are met and that value is delivered in the process. This involves managing various activities, the synchronization of people to align on variable-term objectives, and the execution of tasks towards achieving the goals. According to the Guide, PMs spend up to 90% of their time communicating, and I would have to agree. Before studying the Guide, I had a more conservative prediction that it’s about 75% of their time. The standard’s 90% validates what I have generally considered as the truth: communication is critical to getting any job done let alone achieving any real outcomes in any initiative. Whether it is a successful friendship, relationship, trading partnership, or anything that requires good reciprocity, including a project, communication makes it possible.
Even outside of the project, the PM may have to engage in higher-level meetings in which they are not the key manager. For example, a program manager (PgM) may run the program in which the PM is just one of many project managers involved in the program. In this case, the PM may be engaged in discussions ensuring their project’s needs can be met through securing and sustaining people, budget, and other resources they need to get their project done. They will also be involved in clarifying or reporting that their project is in alignment with what is occurring within the program or above to the portfolio or organization level. The communicating never ends, and while I believe communication is positive, it can be quite the drain especially if the patterns are not optimized. “I was just in four back-to-back meetings… what did I sign up for?” Project management, possibly.
How I coordinated: an anecdote
Where I have acted as the PM within a strong matrix organization, it’s certainly the case that while I had to juggle the complexities of activities and people within the project, I had to do that while ensuring my higher-ups were happy with the progress of the project. It’s one thing to lead my immediate team in understanding the scope of what they have to work on (typically delegated to a business analyst) and ensure it’s developed according to the relevant testing strategy before the work is made live. It’s another to deal with the plethora of other competing objectives involved when doing the work.
Scope as a Competing Constraint
The product owner (PO) might want certain features to be delivered even if the execution methodology would not allow us to be that efficient. I may have to consider whether to overutilize resources, which could make the team upset about not having a reliable work-life balance. In some cases, I would have to consider whether to justify slower delivery even if in some cases the resources may have made mistakes. In other words, there were so many ways to lose, but I was responsible for balancing all of this and deciding what would happen next. Trying to solve this problem is all part of the fun!
Resources as a Competing Constraint
During a senior leadership meeting, I received feedback about having to decrease the number of team members, and this required that I assessed within the project what was best given that I could not negotiate to keep the same number of team members. It is not always the case that the best contributor is the best team member, but sometimes the project’s timeline might not be able to afford inefficiencies.
Technology as a Competing Constraint
The technology and architecture leadership may indicate that the corporation is switching to a new framework that must be adhered to within six months to comply with the agreed IT security policy, but this would cause a major increase in the workload which would certainly cause feature delays. It is possible I could use this information to try to retain the team I thought I was going to have to reduce, and if I am lucky, I could secure an additional team member to help streamline some of the product feature delivery, too!
Risk as a Competing Constraint
I had to take all of this into account, and in situations where risks shift towards one area or another, I have had to keep my eyes and coordination more in that area if the risks were not already managed by or transferred to someone else outside of the project team.
Part of the trick in being a project manager is not only juggling but in getting it all done while running across a tight rope. If I have set up a decent foundation, there will be a large mat on the ground to catch us when we fall in the form of highly supportive team members and supervisors.
Negotiations: Figuring out whether we can get to a win-win
In numerous projects, especially the ones that had multiple product owners, I would have to get in the middle of a prioritization battle to determine whose feature was more important to deliver on time. That battle can be won by getting creative and figuring out how to give both of them what they want without sacrificing the product’s quality, but that can’t always happen. There might be stakeholders who are not at the same level, and that can be difficult as well.
The business stakeholders might want to drive value out of the product and its use by customers, but the operations stakeholders might be suffering because of issues with the product such that throwing more people at it might not stop the flood. Or the program manager just wants to deliver the project on time with as much baseline quality as we can deliver, but the product owner will be disappointed if certain enhancements can’t be delivered despite being forecasted for delivery on the product roadmap.
Beyond communicating with the stakeholders to ensure everyone would be in alignment, I made sure that any action I would take would create value not just for the client’s business but also for my higher-ups. The projects or products I worked on would affect company reputations. In one project, I knew that my success on it would lead to further income streams for the account, so I put in an inordinate amount of effort that was not planned in the budget. I did this beyond my role as just simply a PM, taking it further as a driver of business and sales credibility. I loved every minute of it even during the tougher times!
I have a few more stories to tell, covering product vision, the differences between leadership and management, and influence.
Question that might pop up: leadership style
I have seen variants of these questions around, and I have created my own variants. They are by no means exactly the ones that will pop up on an exam.
What is the leadership style when the leader is hands-off?
A. Servant leader B. Interactional C. Laissez-faire D. Charismatic
My hint is that it’s mostly related to unfettered capitalism as expressed by Adam Smith (the answer is here).
For other mock questions, read more posts from this tag. To learn more about my stories and my experiences as a project manager, get in touch. I have scratched only the surface in this post (and in the next one).