PM-Foundations – Is your project a success?

Many project managers will proudly declare, “This project is a major success – we are delivering on-time and within budget.” When you take time to talk to some of the customers of these projects, you hear a much different story. In many cases, the customer’s version describes a product that was delivered that does not meet their expectations. In other cases, the customer’s version describes processes utilized to deliver the project that were not very collaborative or customer friendly. I refer to cases where you eventually achieve the goals of the project but stakeholders are generally not happy with the way you get there as “winning ugly”.

If there is more to project success than delivering within the boundaries of the triple constraint (time, cost, and quality/scope), how do you judge if a project is successful? In my experience these measures are a good start, but they do not portray the “total picture”. Project success should also take into consideration the impact the project has on the organization, the processes utilized to deliver the project, and how customers feel about the project outcomes.

This post covers my thoughts on what should be considered when defining project success, as well as the project manager’s accountabilities and responsibilities related to project success.

What does success look like?

In the context of project delivery, success is generally defined in terms of attainment of predefined goals. Projects are often judged to be successful based upon more than just the goals/objectives established in the project charter or project management plan – project managers lament this fact. Below are factors I consider when assessing project success.

  • Time & Cost – Is the actual project delivery date and cost less than the baseline delivery date and cost (also taking into consideration the impact of approved changes)? Time and cost are the success factors that project managers talk about the most. These are the factors that project managers are directly responsible for managing. In addition, these success factors are relatively easy to measure and report on.
  • Scope – Did the project deliver the “what” was expected to be delivered? Scope is not limited to the product features and functions. Scope also includes the deliverables that ensure that the product is properly implemented and supported. I have seen my share of projects viewed as failures due to the lack of attention to deliverables such as training, product marketing/adoption, and support processes.
  • Quality – Does the product delivered perform the function it was intended to perform? Many project teams fall into the trap of judging product quality solely based upon the number of defects identified. All it takes is one or two defects to prevent the product from performing as intended. Quality related success measures should be judged based upon the ability to achieve operational goals (e.g., number of transactions processed, average calls per hour), as well as the ability to respond to product related problems.
  • Process – Were processes consistently and effectively utilized to deliver key elements of the project? Processes such as change control, communications, and resource management can significantly influence the perceived success of the project. The predefined goals of the project may have been achieved, but if it was delivered without collaboration or with limited flexibility, stakeholders may not view the outcomes in a positive manner.
  • Significance – Has the project delivered had a positive impact on the organization? Should projects that have limited or no impact on the organization be considered a success? As a project manager, you may say, “It is not my fault the project has not delivered the desired benefits to the organization.” This may be true, however I have seen many examples of projects where what was delivered, or how it was delivered, had a direct impact on the benefits realized. I have also managed projects that were delivered late or over budget, but delivered benefits that far exceeded expectations, and therefore were considered a success.
  • Stakeholders – Are stakeholders happy with the project outcomes? Stakeholders are the people that were involved in or impacted by the project. It is a problem if the overall stakeholder community, or large segments of the stakeholder community, do not speak positively about the project. Feedback can be a very subjective measure of success, but I do believe that how people “feel” is a valid component of the success of the project. In most instances, specific actions can be taken to change the nature of feedback received from stakeholder – do not take this feedback too lightly.

6 ways you can improve the success of the project

I am a firm believer in the fact that the project manager role significantly influences the success of the project. Below are six project management best practice areas that have a direct impact on the success of the project.

1. Project Organization – Forming the project team sounds pretty basic, but it is amazing how many project teams launch the project without performing stakeholder analysis, and defining the project organization. Important elements of the project organization include project sponsors, the core team, and understanding other key stakeholders. Getting the “right” people engaged in the “right” roles has a significant impact on the project teams’ ability to meet the needs of the organization.

2. Baseline Plan – As a project manager you are introduced to new situations all the time (new clients and new projects), and it is extremely important to hit the ground running leading project teams through the planning process. Adapting a consistent planning approach from client to client, and project to project, significantly improves outcomes of the project planning process (both time to market and quality of the plans). Strong baseline plans represent the foundation for a successful project delivery process.

3. Measure Project Performance – This best practice area involves keeping your eye on the appropriate project performance measures to proactively identify potential problems, and engage the team to identify and implement corrective actions. Effective use of project performance metrics helps the project manager identify and implement
the appropriate project delivery adjustments before they become “big problems” that stakeholders are not quick to forget.

4. Collaborate – Stakeholder engagement in project activities has a significant impact on how people feel at the end of the project. Project managers enhance the collaboration on a project by facilitating effective team meetings, implementing collaboration processes & tools, and providing consistent and useful project updates.

5. Manage Change – Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager effectively manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. The level of control and rigor around analyzing and approving changes should be appropriately “sized” to both the organization and the project.

6. Close the Project – At the end of a project, many project managers are busy preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization. Project closure starts with effectively shutting down project activities, validating all product deliverables are complete and key product issues closed, and smoothly transitioning resources to new roles. The second aspect of this best practice area is preparing the project performance report (also referred to as the post-project assessment). Creating the project performance report includes gathering input from key stakeholders, and identifying improvement actions to be implemented either as part of the closeout process or for future projects. These improvement actions can significantly influence stakeholders’ perception of project success.

 

Your comments are appreciated. What is your experience with judging project success?

PM-Foundations – Where do Project Managers Come From?

In my professional life the project management career path has represented a rewarding and challenging destination. In my case, I did not wake up one day and say, “I am going to be a project manager when I grow up.” Project management is a skillset and career that I have developed over many years in the IT industry.

Why is the career path to become a project manager ambiguous? I think the answer to this question is linked to the fact that to become an effective project manager you must do two very different things consistently well:

1. Apply tactical project management related skills. These skills include managing schedules, budgets, and risks (to name a few). These skills must be learned and then applied appropriately in the context of managing projects. Education is helpful to learn these skills, and certifications such as the PMP validate that the project manager has developed the core knowledge base to manage projects. Organization and attention to detail are critical attributes of the project manager to effectively apply the tactical project management skills.

2. Demonstrate the ability to lead people. The project manager must establish a leadership style that is used to form, build, and lead teams to deliver successful project outcomes. This leadership must include specific skills such as facilitation, communication, managing conflict, and building client relationships.

It is often hard to find people that have mastered both elements of becoming a good project manager. Depending on the person’s education and career path, they commonly favor one element over the other. What is the best career path to become a project manager? My opinion is that there is a single correct answer to this question. Below I provide my thoughts on 4 different paths to become a project manager. Many people, including myself, pursue more than one of these paths before becoming a project manager.

Path #1: School to Project Manager

Colleges offer bachelor’s degrees in Project Management. The bachelor’s and master’s degrees are great opportunities to help people with project based experience make the transition to a project management role. However, I struggle with the idea of hiring a person right out of college as a project manager. These candidates may have the “book knowledge” associated with project management, but do not have the experience of applying these skills in “real world” situations, and likely have an underdeveloped leadership style. To me this approach is the same as hiring a person with a sports management degree, and no coaching experience, to be the head coach of a team. My recommendation to people seeking project management roles right out of school is to pursue a contributor role on a project team, or obtain an “apprentice” type project management role (i.e., project analyst or project coordinator) to gain experience and develop into the project management role over a 3-5 year time period. The PMP certification is a great way to validate that they have obtained sufficient experience and practical knowledge to make the transition. It is also helpful for this person to find a senior level project manager to help them develop and manage the appropriate profession development plan.

Path #2: Business Analyst to Project Manager

The business analyst (BA) role plays a significant leadership role on project teams. The BA is responsible for the “what” associated with the project (product content), while the project manager is responsible for the “how” associated with the project (project content). There tends to be more contributor type roles for a BA, and therefore lends itself to a good starting point for project resources. Many business analysts gain project experience and desire to move to the project leadership role. Based upon the ability to exhibit leadership on projects, and gain experience observing the project manager in action, project management can be a natural career transition for business analysts. I recommend business analysts making the transition to project manager obtain the PMP certification to validate they have obtained the knowledge required to perform the new role.

There is often a perception that the project manager role represents a promotion for a BA. I don’t agree with this perspective. Business analysts have the ability to take on as much responsibility, and add as much value, as a project manager. In addition, the BA to PM transition is only for those interested in the opportunities afforded by the project manager role – it is not for those that are passionate about leading the definition and delivery of product content.

Path #3: Technical Lead to Project Manager

Experienced technical resources often take on a leadership role on the project. The project’s technical lead performs some key activities that support the project manager (e.g., task estimating, resource assignments, issue resolution). In absence of a project manager, the technical lead may even be called a project manager. Given the technical lead’s experience working on project teams, and technical leadership capabilities, the technical lead is a logical project management candidate.

In my experience, this is not as common a career path to project manager, primarily because technical resources do not want to give up the technical aspects of their role as a technical lead to become a project manager. Generally the biggest challenge for the technical lead’s transition to project manager is learning and applying the tactical project management related skills (technical leads do not always like this element of the project manager role).

Path #4: Management to Project Manager

On the surface it seems like it would be a “demotion” to move from a management position to a project manager role. However, the scope of a project manager role can be every bit as challenging and fulfilling as that of a resource manager. In my case, I found the role of leading a group of people to accomplish specific and tangible project goals to be more rewarding than leading a larger group of people to accomplish very difficult to measure organizational goals.

This is a great career path based upon the leadership component of the project management equation. The skills and experience of a manager (assuming they were effective managers) translate well into the leadership requirements of a project manager. In many cases a manager will have performed project management responsibilities in the context of fulfilling their management responsibilities. However, in these cases the manager is usually performing the project management function using very informal techniques, many of which need to be “unlearned” when they transition into the project management role. I always recommend that managers making this transition pursue education and certification (PMP) to ensure they have the core tactical project management skills to perform the job. I also recommend the manager find a mentor that has made a similar transition to help them “fill the gaps” from a skills perspective, as well as to make the necessary adjustments to their leadership style.

 

What has been your career path? What have you found helpful or a challenge with that career path?

PM-Foundations – 10 Capabilities of an Effective Project Manager


When interviewing potential project management candidates there are certain qualities, skills, and experiences you are looking for that are part of the DNA of a successful project manager. These qualities, skills, and experiences define the capabilities of a project manager, and their ability to consistently deliver positive project outcomes. These capabilities represent a point in time “snapshot” of where they currently are in their career. I try to look at the “real” potential of a project manager by assessing the impact additional experience and professional development can have on some of their capability shortfalls. You need to consider the candidate’s current capabilities, potential capabilities, and the perceived desire to achieve their potential when making hiring decisions. In this blog I touch on what I consider to be the key capabilities of an effective project manager.

10 Capabilities of an Effective Project Manager

Below are the top 10 things that I believe that project managers must demonstrate or perform well to consistently drive positive project outcomes. As with most of my lists, these are not necessarily in ranked order.

1. Facilitation – Much of what a project manager does involves facilitation – enabling project teams to collaborate to get work done. Project managers facilitate meetings, decision making, and issue resolution (to name a few). Effective facilitators understand the impartial role of the facilitator, ask good questions to promote meaningful discussions, and leverage facilitation tools to achieve the desire results.

2. Attention to Detail – Project managers must “roll their sleeves up” to understand and manage the details associated with the project. Activities like creating/updating a project schedule, tracking the project budget, and managing project risks & issues require the project manager to be comfortable and efficient working with very detailed information. Part of paying attention to details is identifying the details that are important to the success of the project – too many project managers get “lost in the details”.

3. Credibility – It is almost impossible to effectively lead a project if the project manager has not established credibility with the team and key stakeholders. Establishing credibility involves showing you have the confidence, knowledge, and experience to lead the project team. Credibility is established by “saying the right” things during interactions with the team, and more importantly “doing the right” things to drive project results.

4. Financial Aptitude – My major in college was accounting, so I am probably a bit biased on this point. In order to create and manage a project budget, as well as manage key project metrics (e.g., earned value, variance analysis), the project manager must have a strong aptitude to perform financial analysis related activities. Based upon my experience, project managers that do not have a strong financial aptitude try to ignore these aspects of the project, with not so successful results.

5. Technical Understanding – Even if you are not working on software development projects, most projects today involve some sort of technology. Project managers must be able to talk to technical resources and at a minimum understand the essence of their message and the implications on the project. I always cringe when I hear a project manager say, “I am not a technical person.” In my opinion this type of statement has a negative impact on the project manager’s credibility with the technical resources on the team.

6. Tools Savvy – Tools are a significant element of managing projects in most project environments, and the project manager needs to demonstrate the ability to use them effectively to manage the project. This includes project scheduling tools (e.g., MS Project) to manage the schedule, spreadsheets (e.g., Excel) to manage the budget and other project metrics, and presentation tools (e.g., PowerPoint) to facilitate project meetings. In addition, collaboration tools (e.g. SharePoint) are rapidly expanding in the project delivery space to provide a platform for easy access to project information/artifacts.

7. Embrace Conflict – Many people go through life trying to avoid conflict – conflict is unpleasant and stressful. In the context of project management, conflict is often required to get things “out in the open” and resolve issues. Embracing conflict does not mean that you go to project meetings seeking to “pick a fight”. It means that project manager must ensure that the difficult topics get discussed by the team in a timely manner. Project managers must rely on their facilitation skills to bring these difficult discussions to a positive conclusion. Potential problems left unattended do nothing but get bigger over time.

8. Continuous Learning – Every project I work on introduces me to something new. It may be a new tool, a new client industry, a new business process or a new technology. It is this opportunity to learn new things that fuels much of my passion for project management. Lou Holtz’s statement, “If you are not growing, you are dying” is very applicable to the world of project management. Our project environments are ever changing and therefore a project manager must enjoy and seek the opportunities to learn in order to sustain their effectiveness as a project manager.

9. Active Listening – I find that my most effective contributions on the team are achieved by listening to what the team members have to say. Active listening is required to understand what people are doing, identify challenges team members have encountered, and capture ideas to improve project performance. Active listening also provides the project manager with better “peripheral vision” (things that are not in the project manager’s direct line of sight) to identify potential problems or risks. Many project managers feel that leading involves a lot of talking, and I would argue that leading involves much more listening.

10. Flexible – Very rarely does the execution of the project turn out to be exactly as the project has been planned. Therefore the project manager must be able to respond to a “change in plans” and quickly adjust the plan in a manner that keeps the project on-track. The other important aspect of flexibility is the ability to accommodate the needs of your team and key stakeholders. There are many times that a project manager must lead by being a “servant” to the team – happy team members are productive team members.

 

 

 

 

PM-Foundations – Implementing Project Management Best Practices

My company’s project management services are built around the idea that project management is a very mature competency with many available sources of knowledge, and yet companies still struggle with challenged or failed projects. We firmly believe that the implementation and consistent application of project management best practices is what differentiates successful projects from challenged projects. The more ingrained these best practices are in the project management culture, the lower the dependency on the talents and heroic efforts of individual team members.

What Do Best Practices Look Like?

Best practices represent the practical application of the concepts, processes, and tools defined in the PMBOK® and other sources of knowledge. To better explain best practices, below I have broken down the elements of a successful project management best practice implementation.

  • People – Best practices start with hiring good people – people that have the desire, capabilities, and core knowledge to be a professional project leader. When mentoring potential project leaders, I usually recommend pursuing the PMP certification path to validate that they have the base knowledge associated with the project management competency.
  • Concepts/Approach, Processes & Tools – Represents the components of the project management knowledge base utilized to define your best practices, including the knowledge created within your company’s project environment. This knowledge establishes approaches, processes, and tools associated with solving project management problems. The key is to leverage existing sources, and not spend too much time creating new content. This content should be upgraded on a frequent basis through on-going continuous improvement, in the context of completing work in your project environment (e.g., actions from a lessons learned process).
  • Critical Few – Best practices focus on the “critical few” areas that if performed well on a project significantly improve project outcomes. Organizations often “get lost” in building out elaborate processes and tools, when a limited set of best practices is what is required to deliver a project successfully.
  • Practical Application – Best practices are not theoretical or text book solutions. They represent approaches, concepts, and tools that have been consistently and effectively utilized in “actual” situations to delivery positive results on projects. If you cannot provide examples of the best practice in use then maybe you should consider dropping it from your arsenal of best practices.
  • Appropriate Situation – The best practices define the situations that specific approaches, processes, and tools are most effective. “One size does not always fit all” when it comes to use of best practices. The appropriate situation is learned over time, and through collaboration with colleagues and mentors.
  • Artifacts – Creating artifacts within the project office’s knowledge base converts something “done well” on a project into something that can be leveraged for future project efforts. Process documentation and templates are required to ensure that best practices can be implemented in a consistent and effective manner across all projects. I also find it helpful to maintain a library of examples (reference stories) of best practices applied to solve specific problems on projects.

Are these really the “Best” Practices?

One of the notions often challenged around the topic of best practices is that it may be a bit arrogant to propose that your practices are the “best”. There is generally more than one way to solve most project management problems, and very often one way is not significantly better than another. The goal is to consistently utilize project management practices that deliver positive project outcomes. Whether or not the practices are the “best” is irrelevant if they consistently drive the desired results. I use the term “best” practices because it is a term that seems to be understood across the industry, and represents an aspirational goal for the project office (vs. a factual statement).

What are the Benefits of Best Practices?

A thoughtful implementation and diligent application of best practices will drive tangible benefits realized immediately within individual projects, but more importantly by creating a project management culture and competency that consistently meets or exceeds customer expectations. The following represent specific benefits you can expect by implementing and re-enforcing project management best practices:

  • Results – The cornerstone of project management best practices is driving positive project outcomes. These best practices are utilized to ensure that quality products are delivered when they are supposed to be delivered, and based upon the estimated effort / cost to deliver it.
  • Ramp-up – Project managers will become productive leaders on new projects quicker, because they understand the key areas to focus on during the on-boarding process.
  • Productivity – An effective project manager will use and tailor existing approaches, processes, and tools, vs. building and inventing processes “on the fly”. Use of best practices increases the project manager’s capacity to take on more work (increasing their role on the project, or assigning them responsibilities on other projects).
  • Consistency – Consistency unto itself is not a tangible benefit. However, if projects are managed in a consistent manner it is easier for team members to engage in project work because project managers “speak the same language” (utilizing the same processes and tools) across the portfolio of projects. This consistency also improves the ability to integrate projects in a multi-project environment.
  • Continuous Improvement – Placing emphasis on best practices establishes a “baseline” for continuous improvement in your project environment. As teams identify new practices, or enhance existing practices (in the context of completing project work) it becomes natural for the project office to capture the improvement and incorporate it into the best practices utilized across all projects.

How do you Implement Best Practices?

Below are the steps required (not necessarily in this order) to implement a strong best practices centric project management culture in your project office.

  • Identify / Define – Identify the “critical few” best practices that if applied effectively in your organization drive positive project outcomes. Leverage existing resources (within the project management industry, and within your organization) to define these best practices. These best practices are defined in the form of approaches, processes, and tools.
  • Assemble Team – Build a project management team that has the capability and desire to effectively apply the best practices in the context of completing “real” project work. I find that having a core of experienced and skilled project managers is a requirement to a strong best practice centric project management culture. Less experienced project managers can “lean on” the core of experienced project managers for professional development counseling, and advice on specific project situations.
  • Train – On-going training on the best practices is a must. I recommend focusing the training on how to apply the best practices when performing project work. Therefore it is logical to organize the training around the project life cycle. I also recommend that ALL project managers (even senior level project managers) participate in the training – you will not achieve the desired results without getting “everyone on the same page”.
  • Re-enforce – How many times have you attended a training course that you thought was pretty good, and then you did nothing different when you got back to your “real” job? The best practice implementation must involve re-enforcement of the best practices. Our training involves a case study that requires team members to apply the practice in a real situation. Mentors are assigned to the participants to help coach them on the application of the practice, and ensure they really “got it” for effective use on future projects.

PM-Foundations – My Favorite Project Management Slang

Part of my leadership style as a project manager is not taking myself too seriously. I find that creating a challenging and fun atmosphere on the team helps improve both teamwork and project outcomes. My use of project management slang is something that makes people smile, but also helps make a point in a not too serious manner. Below are a few of my favorite project management slang phrases, as well as some project management phrases that I do not like as well. For those of you that know me, you will recognize quite a few of these phrases, because I am not afraid to use them during daily team interactions.

My 9 Favorite Project Management Slang Phrases

1. In the Weeds – This occurs in team meetings when the discussion gets totally off topic. I see this a lot when the team tries to solve an issue rather than just identify the appropriate action items. This also can occur when a team member heads the wrong direction on a task, or attempts to make a task into something bigger than it was intended to be. “I think we might be in the weeds” is a nice way of saying we need to redirect the discussion or work to focus on the things that are required to keep the project headed in the right direction.

2. Arthritic Abandon – This phrase is definitely one of my personal favorites. Arthritic abandon occurs when teams seem to be working real hard, but are getting very little accomplished. A symptom of arthritic abandon is when team members talk about how busy they are, but you are seeing very little progress actually realized in the project schedule. This phenomenon usually points to the need to reassess how work is performed, or decisions made (e.g., too many meetings, or too many approvals).

3. Religious Discussions – I had a boss that said to me one day, “Do you know the difference between a terrorist and a methodologist? The answer is that you can negotiate with a terrorist.” His point was don’t waste time analyzing and discussing methodologies to get work done – select one that is appropriate for your project and use it consistently and effectively. Obtaining consensus on methods and processes is like trying to convert someone’s religious beliefs – it won’t happen. When I encounter a discussion where it appears that we have reached the core of people’s belief systems, I will make the comment that we may be in a bit of a “religious discussion” where there is no “right” answer. At this point you need to raise the discussion up a level, and agree on a path forward that is acceptable to the team (or if necessary mandate the path forward as the project manager).

4. Solving World Hunger – “Solving world hunger” occurs when the team is attempting to solve something that is too big. I use this phrase to encourage the team to break the problem down into components and identify actions items required to move forward. Another version of this phrase is, “I think we might be trying to boil the ocean.”

5. The Wedding Planner – I have several phrases that describe types of project managers. I don’t use these phrases to be mean, but rather mentor PM’s on adjusting their focus or behaviors. My personal favorite is the wedding planner. The wedding planner is more concerned with planning events (e.g., project celebrations, steering committee meetings, milestone reviews) than managing project outcomes. The wedding planner likes planning logistics related issues (e.g., meeting rooms, invitations, AV equipment and meals) more than resolving issues and completing real work. A couple other project manager terms that I have encountered are:

  • Clipboard Project Manager – This is the project manager that walks around and “checks” off tasks as they are completed. This project manager is usually so busy with the details that they do not notice when a major milestone is slipping.
  • Content Free Project Manager – The content free project manager wants nothing to do with understanding the product that is being delivered by the project – that is “not their job”. If you have ever tried it before, it is very difficult to help resolve issues or complete work with zero comprehension of the solution your team is working on.

6. Dog Knot – A dog knot is when project issues have brought progress on the project to a complete stop. This is also referred to as “gridlock”. Disagreements or confusion related to specific issues can cause teams to lose focus on the actions required to “move forward”. A dog knot situation usually requires intervention on the part of the project manager to facilitate issue resolution.

7. Pushing a Rope Uphill – This phrase refers to team members that are trying to do something that is very difficult, and is unlikely to have a positive outcome. The team member’s idea or effort does not fit well within the goals or strategy of the project or organization. A similar phrase is “going against the grain”. I will us this phrase to get team members to drop the idea or effort in the spirit of gaining consensus on the team.

8. This Dog Won’t Hunt – I was introduced to this phrase when managing a product development effort. When describing the lack of market acceptance for the product, the product manager said, “I don’t think this dog is going to hunt”. This phrase gently conveys the message that the project is delivering a solution that is not going to meet the project objectives. This phrase is used either to help the team decide on the appropriate corrective actions, or recommend to cancel the project.

9. Feeding Frenzy – A feeding frenzy refers to something that can occur in a team meeting. One person says something and it causes the team to go on a wild tangent. Generally the feeding frenzy is not positive (a lot of griping can occur in a feeding frenzy). I use the phrase in an attempt to get the team to calm down a bit, and refocus the discussion on the topic at hand.

Not My Favorite PM Slang Phrases

Here are the phrases that I am not as fond of. I don’t like most of these phrases because they are too negative about the project or the project team. The other reason I do not like some of these phrases is that they touch on aspects of the project that should be managed / solved by the project manager.

  • Scope Creep –Some project managers fall back on the excuse that the project is over budget or late because there were constant changes, but often cannot quickly explain the changes that account for the primary deviations from the original plan. Projects with too high a percentage of unexplained variances, is usually an indication of a project with inadequate attention to change control processes. In these cases, too many changes are “flying under the radar” and hence the use of the term “scope creep”.

  • 9 Women cannot have a baby in one month – This phrase refers to the fact that you cannot just “throw” more resources at a project to deliver on a target date. This phrase is not my favorite mainly because it is overused. I also do not like it because it infers that there are limited options that will fix the problems on the project, even additional resources. I believe the project manager is obligated to work with the team to find options to get a project back on track, especially when the sponsor is offering to help with additional resources.

     

  • Death March – The phrase “death march” refers to a project assignment that is doomed from the start due to unrealistic commitments/expectations (aggressive deadlines, under-funded, and short staffed). Referring to your project as a “death march” from the beginning of the project becomes a self-fulfilling prophesy. Honestly, I have never taken on a project that I felt was a “death march”. If the project commitments truly are unrealistic, the “facts” discovered throughout the planning process can be utilized to help reset expectations.

  • And then there was a miracle – This phase is used when the team feels that the only way a successful project outcome will occur is if something beyond their control happens. As a project manager, I like to believe that the team has been empowered to successfully deliver the project. To say that a “miracle” is required is in essence shirking responsibility for the project results, and/or conceding defeat/failure.

PM-Foundations – The Project Charter

Every project needs to start somewhere. Someone in the organization identifies a new idea, a problem to be solved, or a business need to be fulfilled, and initiates the project through some form of communication to the group that manages the project initiation process. Depending on the organization and the type of project request, the initial communication has different names – project charter, business case, enhancement request, service request, or investment proposal (to name a few).

In my experience, the project initiation process is a critical component of the overall project delivery process because the time lost “up-front” identifying and formalizing new projects is seldom recovered throughout the remainder of the project life cycle. No matter what you call the document that is used to initiate the project, the process and content utilized to capture and approve the project concept will have a significant impact on time to market and reduce the number of “false starts” associated with new project requests. Consistent and well-understood project initiation processes and deliverables makes it “easier to do business” with the project delivery organization.

For purposes of this blog, I refer to the project initiation deliverable as the Project Charter. This is the term most commonly utilized within the project management community, and is often adopted as the name of the project initiation deliverable within organizations’ project delivery processes / methodologies.

Project Charter Content

The information captured within the project charter is utilized to provide a high level description of the project concept (business need or problem to be solved), and answer some basic questions utilized to justify approving initiation of the next step in the project delivery process (project planning and execution).

  • Why? Describes the goals and benefits of completing the project. A good project charter will provide a description of tangible benefits to the organization, including quantification of the potential range of benefits (optimistic – realistic – pessimistic).
  • What? Describes the high level scope of the initiative, and the key requirements associated with the request (often in the form of critical success factors).
  • Who? Provides a list of the primary person/organization requesting the project (the project sponsor), and the key people/organizations impact by the project (stakeholders). It is helpful to describe how the people/organizations are impacted (e.g., suppliers, subject matter experts, end users, customers).
  • When? Highlights timing related requirements associated with fulfillment of the project request (e.g., window of opportunity). In some cases, how the project request will be fulfilled is known, and the project charter provides key project milestones and target dates.
  • How? Describes what is known about the project delivery process. In many cases the project is not starting from a “blank piece of paper”. The project may represent an enhancement to an existing product or system, or the implementation of a product / technology that has already been identified or purchased.
  • How much? Establishes funding available to complete the project request (e.g., amount budgeted in the organization’s budget), and/or cost related parameters associated with fulfilling the project need. In many cases, the project charter will define a rough order of magnitude type estimate for completing the project (e.g., +/- 50%).
  • What else? The charter will include any additional information that is relevant to approving the project request and initiating the next step in the project delivery process (e.g., project assumptions or constraints). The project charter may also include an assessment of risks and issues associated with the project request.

Listed below are elements commonly found in a project charter. Many project charters include a summary section that “scores” the request based upon the initial estimates of benefits, costs, timing, and resources. This score is utilized to help evaluate the relative value of the request (compared to other requests) within the project initiation process.

Elements of an Effective Project Charter:

  • Background / Description
  • Goals & Benefits
  • High Level Scope
  • Key Product Requirements
  • Critical Success Factors
  • Proposed Project Delivery Process
  • Project Sponsor & Key Stakeholders
  • Cost Estimates / Targets
  • Target Dates / Milestones
  • Assumptions & Constraints
  • Known Risk & Issues
  • Score / Ranking

Project Charters do not need to be lengthy documents that represent a long and arduous process to complete. The specific content within the project charter should be tailored based upon the type, size and complexity of the project request. The project charter should be viewed by the customer of the project initiation process as an “enabler” vs. a “blocker” to launching a new project.

Who is Responsible for the Project Charter?

Ultimately the person or group that has identified the business need or problem to be solved is responsible for the project charter. However, in my experience, many areas of the organization do not have the experience, knowledge, or skills required to create an effective project charter. Their “best attempt” frequently does not adequately describe the business need, high level scope, or the best approach to fulfill the need. These project charters are often “hung up” in the project initiation process, requiring significant rework and additional justification prior to approval. Again, delays during project initiation are seldom recovered in the remainder of the project delivery process.

To solve for this problem, I recommend assigning a member of the project office to help the project initiator with gathering and documenting the information required to create a strong project charter. If the person assigned is also the person that is anticipated to be the project manager for the initiative (assuming it is approved), assisting the project initiator with the project charter will streamline the project manager’s on-boarding and ramp-up during the official project launch and planning processes.

6 Attributes of a Good Project Charter

1. Written – Although the initial idea may be communicated and vetted verbally, project initiation requires some form of written documentation to efficiently approve the request and launch the project planning effort. In addition, documenting the project charter enables collaboration of key stakeholders, and improvement of the end deliverable.

2. Objective – The project charter should fairly represent the perspectives of all key parties involved and impacted by the project request. Although the project charter is not intended to be a legally binding document, it is expected to be a reasonable representation of the anticipated benefits, as well as the estimated effort required to fulfill the request.

3. Explicit – A project charter should clearly and concisely communicate each of the key elements of the request – goals/benefits, timing, costs, risks/issues. Based upon the information known at the time the project charter is created, these elements should be described in detail, and quantified if possible. In many cases, the use of project assumptions enables quantification of benefits, costs, and timing. Project charters that contain ambiguous elements are often the source of contention and change during the project planning and execution processes.

4. Available – The project charter should be maintained in a location that is available to all stakeholders. Collaboration on the project charter improves the quality of the end deliverable. In addition, the project charter represents a deliverable that will continue to be referenced throughout the project life cycle, particularly during the project planning process.

5. Consistent – Establish a template for the content and organization of the project charter. Within the template describe how the content can be tailored based upon the size, complexity, and type of request. Best practices and lessons learned from previous projects are used to continue to enhance the project charter template.

6. Approved – As defined by the organization’s project initiation process, the project charter should be approved by the appropriate parties (including sign-off) prior to launching the project planning process. All project charters (in process, approved, and rejected) should be maintained in the project office’s project archives.

PM-Foundations – What Does a Project Manager Do?

One of my favorite questions to ask potential project management candidates is, “When you were managing the project what did you actually do throughout the project delivery process?” It is amazing how vague and ambiguous the responses can be.

“I managed the project deliverables.”

“I led the team.”

“I guided the project.”

“I managed customer relationships.”

“I facilitated project planning.” (this one is a little better)

None of these examples very effectively describe what the project manager actually “does” to ensure the project is planned, executed, and closed in a manner that delivers on customer expectations. The other response that I frequently get to this question is a “deep dive” into the content of what was delivered. For some reason candidates think describing what was delivered articulates their contributions to the project outcomes.

The reason I think it is so important for candidates to be able to clearly describe what they do as a project manager is that it helps identify whether or not they consistently do the right things at the right time during the project delivery process. Focusing on the key elements of what a project manager does is also helpful to identify improvement areas and professional development opportunities when coaching and mentoring project managers. Below are 9 of the project management activities that I focus on when working with project managers. I thought about ranking these in order of importance, but honestly I believe these represent the handful of things that are all important for a project manager effectively and efficiently perform to consistently drive positive project outcomes (therefore these are in no particular order).

Top 9 Things a PM Does throughout the Project Life Cycle

1. Create and Manage the Project Schedule – Without a good schedule that directly supports the project objectives (scope, time, and cost), the project manager will struggle to effectively deliver on customer expectations. The project manager has direct responsibility for creating the project schedule, including defining the work breakdown structure (WBS), performing activity definition and sequencing, loading and leveling resources, and performing schedule analysis. During project execution the project manager updates the project schedule in a consistent and timely manner. These updates ensure that the project schedule always provides an accurate picture of work completed, and work remaining to be completed.

2. Create and Manage the Project Budget – The project manager creates the project budget by efficiently leveraging the planning assets created to that point in the process. The project manager performs analysis to develop a project budget that will be understood and approved by the client/stakeholders, and just as importantly can be managed throughout the project life cycle. Creating the project budget includes developing a project staffing plan that details planned resource utilization (in hours), identifying other project costs (e.g., software licenses, infrastructure investments, and travel & expenses), and complying with the organization’s financial processes (e.g., capitalization, investment approval, project budgeting vs. funding). During project execution the project manager updates the project budget with actual hours reported by project resources and other actual costs incurred (e.g., from vendor invoices). The project manager forecasts cost variances based upon costs incurred and estimated cost to complete the project, and identifies / implements corrective actions required to deliver the project within budget.

3. Create the Project Plan – The project management plan represents the key deliverable created during the planning phase of the project that connects the project management activities throughout the project life cycle. The project management plan describes the elements of the baseline project plan (scope, timeline, costs and resources), as well as the approach, processes and tools that will be utilized to manage each component of the project (e.g., cost management, schedule management, change management risk management, roles & responsibilities, project communications). The project manager ensures that a strong project management plan is efficiently created (the project manager generally authors a large portion of the project management plan), and is proactively utilized throughout the project life cycle to successfully deliver on the project objectives.

4. Identify and Manage Risks / Issues – Throughout the project life cycle the project manager facilitated the investigation of project related uncertainties to identify potential risks of things that may occur that would impact the project (scope, cost, or timing). The project manager is responsible for capturing and tracking risks and issues in a manner that minimizes their impact on the project. The project manager ensures that key risks and issues are reviewed on a regular basis, and the appropriate actions are completed to close issues or reduce the impact / probability of risks.

5. Manage Team Meetings – The two most important team meetings that the project manager has responsibility for are the core team and steering committee meetings. Effective planning, facilitation and follow-up for these meeting by the project manager is a key to ensuring that the core team members and project sponsors are well-informed, focused on the right things, and resolving issues in a timely manner. The project manager creates the agenda, organizes information to be presented, facilitates the meeting, communicates meeting outcomes, and initiates / tracks the follow-up actions from the meeting.

6. Manage Change – Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. The project manager establishes the change control process for the project, ensures that potential changes are captured and assessed in a timely manner, implements approved changes by making the appropriate adjustments to the baseline plans, and tracks / communicates the impact of change on the project.

7. Measure and Manage Project Performance – The project manager updates progress against plans (budget and schedule), performs analysis required to accurately interpret the key project performance metrics, and recommends / implements corrective actions. This process is performed in a consistent and timely manner to ensure that problems are identified early on, and the appropriate actions are taken to keep the project on-track.

8. Facilitate Stakeholder Communications – The project manager communicates with key stakeholders in a regular and consistent manner, targeting the messages to specific stakeholder groups using the appropriate communications channels / vehicles (e.g., project update meetings, status reporting).

9. Close the Project – Project closure represents an activity that is often minimized or entirely overlooked by the project manager. At the end of a project, many project managers are hurriedly preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization. Project closure starts with effectively shutting down project activities, validating all product deliverables are complete & key product issues closed, and smoothly transitioning resources to new roles (onto new projects, or within operational functions). The second component of closing the project is gathering customer input about the project, and summarizing the project results in the form of the final project report (also known as the project closeout report). This component of closing the project includes facilitating the lessons learned process to identify improvement opportunities (things done well, or areas for improvement), and to initiate actionable next steps to improve future projects and upgrade the capabilities of the project office.

How do you know if you are doing the right things?

This represents a long list of things to do on a regular basis – how do you make sure you are focused on the right things? Part of the answer to this question depends on where you are in the project life cycle. During the planning phase your focus is on creating the planning deliverables – the schedule, budget, and project management plan. During the execution phase of the project your focus shifts to updating the schedule and budget, tracking risks and issues, managing change, communicating with key stakeholders, and measuring / managing project performance.

The other element of answering this question relates to establishing a personal organization system that the consistently helps you understand and focus on activities that will have the greatest impact on driving positive project outcomes. Neal Whitten, in one of my favorite project management books, “No-Nonsense Advice for Successful Projects”, talks about ensuring that the project manager is managing the top 3 problems. Neal states, “The No. 1 reason projects run into trouble is that the project manager and other project members lose sight of the problems that need the most attention – the top three problems. The top three problems become the top priorities.” I think this concept relates directly to the everyday life of a project manager. What are the top 3 things that need to be performed / resolved to keep the project moving in the right direction? There are many personal organization techniques that you can use as a project manager to ensure you are focused on the right things. I utilize a project planning pad (see below) to record and prioritize my activities at the beginning of the week. This tool personally helps me maintain focus on the “right things” throughout the week, and summarize accomplishments and open issues at the end of the week. The same organization system does not work for everyone, but my personal opinion is that effective project managers consistently utilize personal organization processes / tools of some shape or form.

 

On a Personal Note: I got the idea to write this blog when I was talking to a good friend of mine the other day, Mark Ducharme, about what people do (at work). He said I know that you are a project manager, but I have no idea what that means in terms of what you actually do when you go to work each day. Thanks for asking Mark!

PM-Foundations – Organizing Your WBS

Creating a well-organized Work Breakdown Structure (WBS) is always on my list of “critical few” project management best practice areas. The WBS is utilized to effectively define the scope of the project, decomposing the work down into components that can be estimated, scheduled, and tracked/controlled throughout the project life cycle. The WBS makes the scope of the project actionable in the form of a deliverable oriented and hierarchical view of the work. The WBS defines the scope of the project down to the lowest level deliverables called work packages.

One of the most common questions I get when discussing the WBS with project teams is, “What is the best way to organize the project deliverables?” A lot of people think the answer must be obvious, because it does not seem to get discussed much by the team when the WBS takes its initial shape / form. It is not at all a stupid question. There are two very different ways that team members think about the project. One way of thinking about the project is focused on the product that is being created, and the other perspective is based upon how the project work will be completed. Selecting one school of thought over the other will drive a totally different end result in terms of the organization of the WBS. As the project manager, you have to live with the organization of your WBS throughout the project life cycle (it drives the organization of the project schedule, as well as the monitoring / controlling processes), therefore you want to be sure you have purposefully selected an organization approach that works for the project team.

Product Based WBS Organization

For those of us with experience in a manufacturing environment, you are familiar with the concept of the bill of material. The bill of material describes how to build a product from the end product down to the lowest level parts or components. The bill of material is utilized to manage building products in a repeatable, efficient, and cost effective manner (automated utilizing an ERP system). When designing or developing a new product, the bill of material is a logical manner to organize the work that needs to be completed. For product development type projects, organizing the WBS in this manner helps the team think about and visualize whether or not they have effectively accounted for and planned all aspects of the product. This approach also provides an understanding of how different aspects of the product are coming together as the product development effort progresses.

Benefits

Downside

  • Provides the ability to trace the components of the product down to the lowest level sub-components
  • Improves the visibility of the current status of product components (particularly important when working with suppliers)
  • Engineers relate well to the WBS organization structure
  • The WBS is not organized from “beginning to end” of the project life cycle
  • Top levels of the WBS remain open until the end of the project
  • Non-product related deliverables do not fit well in the WBS (unless they are define as part of product’s the bill of material structure)

Project Based WBS Organization

As a project manager, I generally think about the project effort in terms of how the work is going to be completed (based upon the timing and dependencies associated with deliverables). With this approach the work is grouped into work streams (sub-projects), and project phases (defined with major milestones). As you get into lower levels of the WBS the organization of deliverables is based upon the different components of the project or product. This approach allows the project manager to update the project “from top to bottom” as the project progresses (assuming the project progresses in pretty much the same manner as it was planned).

Benefits

Downside

  • The “flow” of the WBS relates closely to the way project work will be completed
  • As work is completed, components of the WBS can be “closed”
  • Generally, easier for project managers to update progress
  • Difficult to utilize the WBS to obtain/communicate the “bill of materials” relating to the product
  • Difficult to highlight the status of specific product components
  • Engineers may struggle with understanding the schedule (and often complain about it)

 

What is the Best Fit for My Project?

There are good reasons to organize your WBS from both the product and project perspective. Below are several factors to take into consideration when you are working with your team to determine the best approach for organizing your WBS.

  • Standalone vs. Dependent Work Efforts – Where are the majority of the dependencies and interrelationships within the separate work efforts? Are the dependencies more focused on the product components or the phases of the project? Are the project milestones tied to the product components or gates in the project life cycle? It is much easier to manage dependencies in a vertical manner within a single work stream, rather than in a horizontal manner across multiple work streams.
  • Wide vs. Deep – Based upon my experience, it is much easier to manage a project that has a WBS that is deeper (vertical) than it is wide (horizontal). Part of this preference goes back to the fact that it is easier to manage dependencies within a single work stream (vs. across work streams). However, I also find that it is easier to manage and measure progress of the overall project (solution) if there are fewer separate work streams that link directly to the highest level of the WBS (the over solution / project summary). For example, if there are 15 major product components associated with your project, with significant dependencies across the components, you should have a good case for organizing the WBS around the project life cycle.
  • Who Cares? – Who are going to be the major consumers of the information maintained within the WBS and the project schedule? Is the effort more product or project focused? If it is a very product focused effort, largely comprised of a team of engineers, you may be fighting an uphill battle to suggest that the WBS should be organized based upon the project phases.
  • What Does Progress Look Like? – How will you be receiving updates on project progress? Will progress updates be organized around separate product related work efforts, or based upon the project phases and upcoming project milestones? Again, the answer to these questions will be largely dependent upon the composition and focus of your project team.
  • Iterative Implications – When the team makes the decision to deliver the project in an iterative manner, they are making the decision that the WBS needs to be organized around the iterations. Iterations are time based, and therefore the WBS takes on a project based organization structure (with the project phases being the individual iterations and milestones for deployments).
  • Either approach will work – As you can tell from my analysis above, I am a project manager and obviously favor one approach over the other. The bottom line is, either approach can work for you and the project team. I can honestly say that some of my most successful project were managed with a product based WBS. In some cases additional steps are required in the WBS definition, and schedule set-up to provide views of the schedule / status from both a product and project perspective. This can be accomplished in MS Project by creating custom fields and special views (using sort and filter functions with the custom fields).

PM-Foundations – Creating an Effective Statement of Work (SOW)

Having spent many years on both sides of the table (client and consultant), I have a pretty balanced perspective of what makes partnerships work well. Most importantly I have seen my share of success and challenges as a result of bad client – vendor relationships. These bad relationships are often the source of less optimal project outcomes, or at a minimum the reason the team had to “win ugly”.

I have a firm belief that the quality of the partnership, and the resulting project outcomes, start right up-front when the agreement between the client and vendor is created. The goal of this agreement is to define the products / services the vendor will provide that will satisfy the client’s needs, and how the vendor will be fairly compensated for the products / services delivered. Problems with the agreement can result in a client not getting what they need, or a vendor not getting fairly compensated for what they delivered. Here are a couple scenarios that help illustrate this point:

Scenario 1: The Unhappy Client

The client sends out a Request for Proposal (RFP) to create a new web site. The client has definite ideas in mind in terms of what the new web site needs to look like and do to drive the desired benefits to the organization. The vendor expresses that this project should be pretty straightforward and they provide the lowest time and cost estimates. They are awarded the engagement largely based upon these estimates. As the project progresses, the vendor expresses that there are more requirements / complexities associated with the solution than originally defined in the SOW. Many change orders ensue and the project slips. Finally, the project is completed, but the client had to forgo certain desired features, paid more than planned, and went “live” with the solution much after the original management commitments. This is not a happy client.

Scenario 2: The Damaged Vendor

The vendor provides a proposal to develop a collaboration portal for their client. The client says that they really want to do business with the vendor, but they do not have funding for the amount proposed. The client convinces the vendor that they can “cut some corners” in a couple areas to meet the desired cost of the engagement. As work progresses, client stakeholders keep pushing for doing things “the right way”, and in the spirit of maintaining a positive relationship the vendor performs much of the work originally proposed. The project is delivered successfully, but not without much pain and additional effort on the part of the vendor.

The processes utilized to create and approve the Statement of Work (SOW) can help both parties establish a strong partnership and achieve positive project outcomes. My insights on this topic are not all about introducing overhead and bureaucracy to crank out an “iron clad” contract, but rather how the client and vendor can work collaboratively to create an agreement that sets up both parties for success (the overused term for this is creating “win-win” situation).

6 Tips on Creating an Effective SOW

1. Understanding of the Problem – In my opinion the most important element of creating a strong agreement is ensuring that the problem to be solved is well understood by all parties involved. Adequate effort must be invested in the client describing the problem, the vendor performing discovery to understand the problem and associated requirements, and the vendor describing their approach to solve the problem. Many of my experiences with bad client – vendor relationships can be traced back to when this process was not completed well. I believe that vendors can consistently separate themselves from the competition by taking the extra steps required to understand the client problem, and effectively articulate their proposed approach to solve the problem.

2. Creating an Acceptable Delivery Approach – The processes and tools the vendor will use to deliver the solution must be compatible with client processes and tools (e.g. SDLC, project management tool). In addition, the approach must be one that the vendor is comfortable using to successfully deliver the solution. If there are specific processes or tools that are critical to compliance with client methodologies, they should be understood and specified in the SOW.

3. Establishing Realistic Estimates & Targets – Both parties must be comfortable with the effort and timelines defined in the SOW. Agreeing to estimates or dates that are not reasonable or achievable will lead to problems in the project delivery process. One of my favorite statements is “the work is what it is, and just saying it will be so does not make it so”. If there are specific concerns about the estimates or timelines, it is much easier to discuss and resolve the issues before the work has started, rather than after a significant problem is encountered during the project delivery process.

4. Defining Roles & Responsibilities – Many agreements fall short in the area of defining roles and responsibilities. Vendors do a decent job of describing the resources that they will require to deliver the solution, but they do not spend as much energy on describing client resource requirements. I think it is most effective to describe the client roles and responsibilities in the context of a RACI Chart, and highlight deliverables that the client is responsible for or is making significant contributions to. In addition, it is important to highlight specific resources or skill sets that will be required to complete key deliverables.

5. Minimizing Assumptions – Assumptions are often overused in an agreement to try to protect a party against negative situations. My experience is that these assumptions are forgotten the moment the SOW is signed, and they can become a source of contention during the project delivery process. The classic “CYA” assumption found in many SOWs is “the vendor will have timely access to client resources to define requirements and approve deliverables.” First of all this statement is not actionable, and secondly it is not helpful to successful project delivery. If there are areas of concern, work together to address the issues in an actionable manner either within the definition scope of the engagement or the project delivery approach.

6. Accounting for Progressive Elaboration – Almost all agreements involve “unknowns”. The SOW must accommodate how the unknown will be turned into a known, as well as how project plans will be adjusted throughout the project delivery process. The most common way (but not necessarily the best way) that agreements account for unknowns is through the description of the change order process. A change order process is required when an unknown is not described in the SOW, and requires additional work when it is discovered in the project delivery process. However, many unknowns are associated with clarifications required (vs. change) during the project delivery process and these situations are best accommodated by reflecting iterations in the delivery approach to confirm and adjust plans accordingly.

PM-Foundations – Why Manage a Project?

The other day I was at a client participating in a discussion on strengthening the portfolio management processes, when someone asked the question, “Do we understand what a project is?” This question made me smile. After all of this discussion, we don’t know what a project is, really? From my perspective it is best to keep the definition of a project very straightforward. A project is an effort to achieve a specific goal that has a definitive beginning and end.

 

When you break down this statement, the following are the important elements:

  • Effort – Projects require resources to complete. These resources generally include money and people. Therefore events that “just happen” are not considered projects (many refer to these as Acts of God).
  • Goal – The goal represents the desired outcome that the project is attempting to achieve. The goal is what defines the end of the project.
  • Beginning and End – The most important element of the definition of a project is that it is a temporary endeavor. Projects always have a beginning and an end (even if the end does not represent a successful outcome). The fact that a project is a temporary endeavor is what differentiates it from an operational process. Operational processes are repeated on a day to day basis to perform on-going business functions.

While most people can quickly agree upon the definition of a project, I think the more important question in the context of portfolio management is, “Which efforts should be purposefully and formally managed as projects?” Many project management enthusiasts would respond to this question with a passionate, “Everything, of course!” I would counter that projects can be managed as actions planned and executed within the context of operational processes. For example, I have seen many continuous improvement type initiatives successfully run “in-line” with the completion of operational work. From my perspective, the organization needs to define the efforts that should be separated from operational work, and managed as part of the project portfolio. This approach allows organizations to focus on achieving successful outcomes on the efforts that directly align with business strategies / priorities. Projects that do not fit in the project portfolio are either thrown out, or completed as part of performing normal business operations.

5 Guidelines for When to Manage an Effort as a Project

Below are my top 5 reasons to formalize an effort as a project, and manage it within the project portfolio.

1. Strategic Initiative – If an effort is tied directly to one of the organization’s key strategies or top priorities, it must be formalized as a project. These efforts need the visibility and rigor that a project provides to ensure the organization is demonstrating and communicating progress on its key strategies.

2. Requires Funding – Efforts that require additional funding / resources are difficult to run “under the radar”. The project initiation process facilitates the justification and approval of funds for these efforts. This process ensures that the organization is investing in the “right” initiatives.

3. Involves Opportunity Cost – An initiative may not require incremental funds, but involves a decision to reassign resources from another effort to initiate this effort. There is an opportunity cost related to stopping or slowing the other effort. Again, the project initiation process facilitates making decisions of this nature, and ensures that resources are working on the “right” initiatives.

4. Cross-Functional – Many efforts require facilitation of decisions and coordination of resources across different areas within the organization. Formalizing the effort as a project enables the level of coordination required to ensure its success.

5. Something New – When an effort is introducing something new to the organization (e.g., process, product, or technology) the effort needs a higher level of visibility to ensure the organization is prepared to accept and effectively leverage the new capability. Formalizing the effort as a project provides this increased level of visibility.

When do you need a project manager?

I feel obligated to discuss a related and somewhat controversial question within the project management community. When should a project manager be assigned to manage a project? From my perspective, all projects must have someone who performs the role of the project manager. I do not believe that projects will be consistently successful without someone that is formally responsible and accountable for what is delivered, when, and how much it costs. The question then becomes, when should the project manager assigned be a dedicated and fully qualified project manager, rather than a person that is performing the role as part of another role on the team (e.g., team lead)? Although I am of the belief that projects are generally more successful with a dedicated and fully qualified project manager performing the role, I do think there are projects and situations that can be successful without one. It is important to understand the project and situation when making the determination of who will perform the project manager role on the team. Here are some things to consider when selecting the project manager for your project.

  • Strategic – Is a key priority or strategy of the organization tied to the success of the project? If the answer to this question is “yes”, you should have a “real” project manager assigned to manage the project. It is common sense that a competent project manager will significantly reduce the risk of a challenged or failed project. Why put a key company priority at risk by cutting a corner on the project manager role?
  • Size & Complexity – As the number of deliverables and activities grows on an effort, so does the need for a qualified project manager on the project. The best indicator of complexity is the number and type of dependencies (both internal to the project, as well as dependencies on external activities or projects). An experienced project manager is going to do a much better job managing a large and complex project schedule, than someone who is performing the function as part of another role. In addition, an experienced project manager will more effectively manage the increased level of change that comes with larger and more complex projects.
  • Resources – Is the core team and stakeholder community cross-functional? Diversity on project teams helps drive better project outcomes, but also introduces challenges in terms of leading and controlling the project. An experienced project manager will more effectively establish and manage expectations on the cross functional core team and within the overall stakeholder community.
  • Cost – Is the cost of the project material to the organization (based upon impact on the investment portfolio or operating results)? Effectively managing a project budget is one of the most common areas that trips up an inexperienced project manager. Experienced project managers understand how to prepare a budget, forecast variances, and as required, implement corrective actions.