Good Projects and Bad Projects to Have in Your Portfolio

Are projects the only reasonable way to develop products? Do you, as a portfolio manager, use projects as your only means to add value?

Projects “Cargo Cult”

According to the PwC global project management report, 97% of organizations believe that project management is critical to business performance and organizational success. However, the trust that organizations place in such projects backfires when managers, because projects worked for them in the past, start to automatically create projects for every possible change.

For example, an organization decides to create a commercial software product that would automate creation of expense notes for traveling employees:

The product manager (PdM): “I would like to create a project to deliver the first version of my product. The business case for my product has been approved by senior management.”

PMO: “We will appoint a project manager and start a project.”

The new project manager (PjM): “I am desperately trying to figure out the scope and constraints of this project, but there is just not enough data.”

The product manager (PdM): “Here are some features we would really like to have in the first version. We could have a feature to scan paper bills, optical text recognition to convert them into text, and perhaps an integration with some ERP plus a bunch of small features. Here’s the full list.”

The new project manager (PjM): “I will put these features in the scope statement. As we do not have any timeline, I will set an artificial deadline to keep the team “motivated” to deliver. Now, let’s kick off!”

Needless to say, this project will not deliver best value to the customers and, as a result, to the performing organization. In addition to poor business results, the teams will likely be demotivated, and the future of the product will not be the best.
(Hint: Never do such projects in real life!)

Instead of being a useful means to deliver value, such project management practices become a ‘cargo cult.’ Because projects are supposed to have a scope statement, budgets, and timelines, managers would start enthusiastically defining them – and, in case of absence of the real data about project scope and constraints, they would provide artificial or unverified data just to keep the projects ‘SMART.’ In reality, these projects are very far from being smart.

Alternatives for ‘Bad Projects’

Back to portfolio management. Contrary to popular belief, portfolios do not consist solely of projects. Project portfolio management defines a portfolio as a collection of projects, programs and operations, managed as a group to achieve strategic objectives.

It is up to you, as a portfolio manager, to decide what would be the best means to achieve the goals of your organization.

For example, in the situation above, you could start a team to work in a continuous delivery mode as software development operations. The team would deliver small increments, and continuously adjust the course based on user feedback.

(source: PMI standard for Portfolio management, 3rd edition)

Instead of a ‘bad’ software or IT project, you could choose DevOps to deliver value to your portfolio. In other cases, instead of running a large ‘bad’ project with a lot of interdependencies, consider starting a program to coordinate several individual smaller projects.

Not All Projects Are ‘Bad’

There are a lot of alarming statistics on the Internet about the failure rates of projects. Question: Does this mean that projects are to be avoided in your portfolio?

Further analysis of the statistics suggest that it does not. In high-performing organizations, a reassuring 89% of projects meet their objectives in contrast to low-performers, where only 36% of projects succeed. There is nothing ‘flawed’ in the concept of the projects, but you have to have the quality of the high-performers to successfully run projects.

In a high-performing portfolio, not only the projects are managed correctly, but also – and in my opinion more importantly – the right projects are managed. ‘Good’ projects have clear, SMART goals, reasonable constraints, adequate resources, and are aligned with the strategy of your organization.

One of the critical factors is the project size. Statistics suggest that small projects are eight times more successful than large projects!

For example, to make sure your EU customer data is properly protected, you would like your IT systems and business processes to comply with GDPR by 25th of May 2018.

You perform an audit of your systems and identify all the potential gaps you need to address. You make sure that legal, security, IT, software, and quality control teams, understand the challenge and have sufficient resources to move forward. You also have the full support of executive management. Your preliminary estimation shows that the total cost would be about 150-300kEUR.

In this case, starting a project could be the right choice to achieve compliance on time.

Conclusion, or When and When Not to Start a Project

Having ‘bad’ projects in your portfolio can lead to poor business results, low team morale, and sub-optimal product decisions.

Do not include such projects in your portfolio. Instead, consider other possibilities, such as creating a program and breaking the big project down into smaller projects. Sometimes, you will want to start operations to achieve the business objective instead of having a project or a sequence of projects.

Start a project when:

  • There is a clear mid or long-term goal to achieve
  • There are constraints to be met
  • Coordinated work of a (cross-functional) team is required
  • The size is reasonable to manage as one project

Do not start a project when:

  • The goal is not clear or a lot of change is expected.
    Consider an investigation project first, or continuous elaboration and delivery operations
  • There are no known time/cost constraints.
    Consider operations;
  • The effort is too large.
    Consider starting a program.

The Key to Good Project Kickoff

You know something is wrong when people on your project team come to meetings unprepared and waste time on endless discussions, find other things to do than what your project requires, and do not openly acknowledge there is a problem.

These symptoms indicate a problem that appeared as early as your project kickoff.

(source: clipartfest.com)

Here is how to do kickoff meetings that work.

Importance of the project kickoff meeting

The kickoff meeting is where all stakeholders involved in your project get on the same page, regarding the goals, roles and responsibilities, constraints, risks, and all other aspects of the project management plan.

It is necessary for project success that the stakeholders share the understanding of the project goals, know the plan, and have confidence in the project – and it starts with the kickoff.

If you do all the preparatory work right, the stakeholders will know a lot information you share on the kickoff meeting. Everybody should know why the project is done, the main factors that influence the project, and have at least some idea about the plan, because you actively involved the stakeholders in the preparation.

In the meeting, the stakeholders will meet each other, confirm their understanding of the goals, discuss their role in the project outcome, and interact with each other to clarify and strengthen their working relationship on the project. For example, the suppliers could align with the production on the detailed delivery schedule and the risk mitigation plan. Or, your team could ask about how you will communicate with the product manager if changes to the project requirements are needed. Such discussions will help to create lines of communication, flag important risks you might have overlooked, see new opportunities, resulting in more confidence and commitment.

All major stakeholders of your project should attend. The project manager, the project sponsor, the project customer, and the project team must be there. Depending on the situation, consider inviting other major stakeholders, such as the program and portfolio managers, functional managers, or senior management.

Conduct the kickoff meeting before the bulk of the work related to the project execution is started. However, usually, some project work would have been done already, for example prototyping work aimed to rule out major risks related to the technical feasibility.

(Source: slideshare.net)

Why kicking off too early may hurt your project

The timing of the kickoff meeting is important for it to have maximum positive effect on your project.

However, put the emphasis not on the timing, but on the content quality. Some managers believe that, until the project is kicked off, no work is done, and the resources are sitting idle and therefore push for the early kickoff at all costs. Such managers do a huge disservice to their projects with ill-prepared kickoffs done in haste.

At the kickoff, if you only bring a vague idea of what the project is about, but do not set realistic goals and the plan on how to get there, you will probably create no engagement or accountability from your stakeholders. People will leave the room with no clue of what they should do next. Were they merely informed about the project? Are there any expectations from them specifically? What are the next steps?

Later, when it is time to act, the stakeholders will debate about what the goals of the project are and who should do what; they will question every aspect of the project and the momentum to drive the project forward will just not be there.

Get a commitment

Your stakeholders should leave the room with a commitment to achieve the project goals and agree on the plan to do so.

To get the commitment of the stakeholders, you will need to work closely with them before the kickoff to define and sharpen the following:

  • Why the project is done. With your project sponsor, prepare the context and the business case. With the portfolio manager / PMO, align why this project was selected among others (see two simple questions to the portfolio management).
  • Project goals. With your project sponsor, define the goals. Usually, you will want your goals to be SMART.
  • Project constraints. With the sponsor, resource managers, PMO, and other stakeholders, define the time, budget, scope, quality, and other factors that constrain the project.
  • Plan how to plan. Define your approach to planning. You can use rolling-wave planning approach or plan the project scope upfront.
  • Scope of work and estimates. With the project team and other stakeholders, prepare the project scope and estimates for the time and cost. Create the baseline budget and schedule.
  • Major risks and opportunities that affect the project and what to do about them. Have a meeting with your stakeholders to identify the major risks and opportunities and decide how you will manage them. If you have a good risk management plan, your stakeholders will be more confident in the successful outcome.
  • Who is doing what. With your major stakeholders, define the roles and responsibilities on the project. You can use the RACI model.
  • Next steps. There are two major reasons you should clearly articulate the next steps. First, as beautifully shown in Cliff Giley’s article, it can sometimes take too much effort to agree on “the whole thing”, and you do not want to drown in small questions. Next steps will provide a good basis for everyone to start. Second, well-defined next steps create a dynamic feeling about the project kickoff and allow you and your team to jump into action immediately.

If you do your homework well before the project kickoff and conduct the meeting with the right people at the right time, you will get a lot more commitment and confidence in the project success.