What would you do if you were given a super power…? No… not flying or saving the world…but rather…. the ability to say “yes” or “no” to the projects your company is working on…. And with each of your “yes’s”, there would be a resource allocation (money and people).

Because of your super power, or “super yes”, your company would be developing new products and 200 of the product developers (that you manage) would be working on the projects of your choice.  Wouldn’t that be cool?

But then imagine that your company actually needs 500 product developers, and your budget is a quarter of what you really need.  Imagine all of the angry BU Presidents sending you nasty messages (after you denied their projects and told them you don’t have any free resources to support their ideas).

And then finally, imagine that at the end of the year, you (and your team) are rated based on the projects you selected, productivity you delivered or the innovation that came out of your shop.  And imagine that your and your team bonus depends on it!

Would you still like that?

How would you select the projects that your team would work on?  Which projects would you reject?  How would you manage angry BUs who are unable to deliver their targets because of your decision?  How would you make this process “emotion-free” and objective, so you wouldn’t be the most hated man/woman in the company?

Last week, I was invited to a meeting with the head of R&D who asked me to come up with the matrix for the Stage Gate process and (human) resource allocation.  In other words … I was asked to create a template that would help my company to decide if the project should obtain our “super yes” status.

During my research (yes, I wanted to know what KPIs other companies are using) I came across an article “Measuring Project Success Using Business KPIs” (http://www.projecttimes.com/articles/measuring-project-success-using-business-kpis.html).  According to the author, good KPIs are

• Aligned—Agree with the specific organization’s vision, strategy, and objectives.
• Optimized—The KPIs should be focused on providing organization-wide strategic value rather than on non-critical local business outcomes. Selection of the wrong KPI can result in counterproductive behavior and sub-optimized results.
• Measurable—Can be quantified/measured.
• Realistic—Must be cost effective and fit into the organization’s culture and constraints and achievable within the given timeframe.
• Attainable—Requires targets to be set that are observable, achievable, reasonable, and credible under expected conditions as well as independently validated.
• Clear—Clear and focused to avoid misinterpretation or ambiguity.
• Understood—Individuals and groups know how their behaviors and activities contribute to achieving the KPI.
• Predictive—The KPI may be compared to historical data over a reasonably long time so that trends can be identified.
• Agreed—All stakeholders should agree and share responsibility for achieving the KPI target.
• Reported—Regular reports are made available to all stakeholders and contributors so they know the current status and are able to take corrective action if needed.

The author also mentions that there are about 75 measurements that performance experts use, but none of the measurements mentioned in this article is listing the one we decided to use…

In order to assign the resources to a proposed project, our team decided to use NPV/Man days.  So… we will not picking/selecting projects with a high NVP but lengthy in time and with a high headcount requirement.  We can’t afford to tie our resources for months in those projects.

Instead, we will be picking and approving projects that have high NPV, that will be easy (and quick) to implement, that will not tie our resources for months, and that will bring the highest return per resource.

Do you think I made the right recommendation?

 

In one of my previous jobs, I was a part of a project that included a big, strategic initiative.  It included a purchase of a breakthrough manufacturing technology that didn’t exist on a commercial scale (yet).  Purchasing this technology would make my company a leader in that category, but time was of the essence and the team needed to act quickly.  The company that produced that technology had the capacity to manufacture only 3 units per year and we needed to get our hands on that piece of equipment fast.

Our R&D/engineering team studied specs, scoped locations where the technology was going to be installed, while our finance team drafted Appropriation Request and our Legal team drafted legal documents.

The business case was presented to the Leadership Committee as a big, strategic and time-sensitive initiative and within 5 weeks the team obtained approval to spend $XXMM.   All estimates were done at a high level, but we all agreed that assumptions were conservative and the contingency of 20% was added to the numbers.  We all felt good about the project.

The project started shortly after that. We made the payment, started building the piece of technology and then…..  new news arrived.  While we could manufacture new products (using this new technology)  ….our manufacturing plant didn’t have enough capacity to package this new product!  How did that happen?   Who was to blame?  How was that missed?  Was packaging capacity in or out of the scope?

The business lesson of defining (or not defining) the scope of the project was painful and very costly.  Underestimating project scope will always undervalue the cost.   It will change the profitability of the project or potentially, the ultimate decision of launching or not launching that product…

Changes to the project scope happen all the time but they might be costly and embarrassing.  While the author of  Scope Change Management: Keeping Projects on Track (http://www.technologyexecutivesclub.com/Articles/management/artScopeChangeManagement.php) emphasizes that  “controlling and managing scope change is critical to the success of any project, as scope changes can significantly impact the cost, schedule, risks and quality of the entire effort”  I think Project Managers must think holistically and strategically.  They must understand how their work fits into their company’s strategic objectives, how their project will impact other work components, departments and processes.  Understanding these elements is crucial to the Project Managers who would like to avoid scope changes and who would like to avoid embarrassment of partially or insufficiently defining a project scope.

According to authors of the article called:  FOUR TECHNIQUES FOR DEFINING PROJECT SCOPE  http://www.jamasoftware.com/wp-content/uploads/documents/wiegers-four-techniques-for-defining-project-scope.pdf  there are four steps in defining a successful project scope:

VISION AND SCOPE (Authors describe product vision and project scope as “Vision and Scope” defines Project “interfaces” with the rest of the world. )

USE CASE DIAGRAM (Visual illustration of interfaces between project and external world)

FEATURE LEVELS (Chart of users mapped to external entities)

SYSTEM EVENT (Describes features of the project)

Although the article was targeting more of a software implementation, I think these components are universal and serve as good guidance to help successful PMs define a winning Project Scope.

The scope, finances and the outcome of the project at (described above) would have been totally different if PM used these techniques.