Align Project Selection with Company Objectives using KPIs
By abhijit.kakhandiki on Sep 07, 2008
This question was brought up by a few customers on my recent trip to Asia. Customers want to know how to manage the phase-gate process in a more objective manner, so that the rationale behind keeping / killing or putting projects on hold is clearly documented.
In the absence of objectivity, product development organizations tend to lose alignment between company strategy and project selection or prioritization. The more important loss however, could be "learning from failure", which is very important for innovation since innovation often involves unknown and unforeseen risks. Any prior experience from previous projects developing similar products is extremely important because it highlights what not to do and serves to mitigate risks to some extent. "This decision was taken upon review by senior management" just does not provide such important learnings. Learning from failure is important in order to achieve 'process maturity' (measured by such models as Capability Maturity Model or CMM). More on process maturity and excellence in later blog posts...
Objectivity in project selection can be achieved by defining Key Performance Indicators (KPIs) at each gate. What KPIs should be used for various gates in a product development process (PDP) is an entire topic in itself and deserves a separate blog. KPIs will vary by the product development phase as well as by industry. E.g. KPIs for upstream phases such as Concept and Feasibility phases should focus on alignment with strategy, potential market size, technological risks etc. KPIs for later phases such as Prototype and Launch phases should focus on manufacturability, distribution models etc. Many business consulting services are available to help companies define their KPIs based on their current strategic direction.
This blog post focuses on how to setup KPIs in Agile Product Portfolio Management (PPM). Having defined the KPIs for each phase of the product development process, the next step is to set them up in Agile PPM. The key to modeling KPIs is realizing how phase-gate methodology operates. Work is done in phases and reviewed in gates. Consequently, the data to support KPI values can be collected / input during the phases, but the KPIs themselves need to be attributes of and populated for the various gates. E.g. if Strategic Alignment is one of the KPIs for the Concept Gate, there could be a supporting business case document that could be created in on the tasks of the concept phase, but the 'Strategic Alignment' KPI itself would be an attribute on the Concept Gate and could be populated with a value of High, Medium or Low. This KPI could be reviewed during this Gate review and appropriate keep / kill / hold decisions could be taken at this point in time based on its (and other KPI) value(s).
Since KPIs will vary depending on the phase of the product development lifecycle, you have to subclass Gates and utilize Page 3 flex fields to represent them. The Gate subclasses could be named after the corresponding phases e.g. Concept Gate, Feasibility Gate, Development Gate, Prototype Gate, Launch Gate etc. or simply named Gate1, Gate2, Gate3 etc. Some companies refer to Gates as Decision Points, so these subclasses could be DP1, DP2, DP3 etc. as well. In a company where product development processes vary by product line, there needs to be some rationalization of how many Gates subclasses are required. Such rationalization should be based on the end goal i.e. KPIs, rather than process and phase differences. If there only exist minor differences in the KPIs between various processes, multiple gates subclasses can be collapsed into one by introducing 'N/A' (Not Applicable) values for some KPIs.
In the previous example, 'Strategic Alignment' KPI was setup as a list attribute on the Concept Gate with possible values of (High, Medium, Low). Other examples of these include Target Market, and Geographical Region. Similarly, 'Technical Feasibility' with values (Possible, Impossible, Need Research) and 'Potential Revenue in first 2 years' with appropriate monetary values could be KPIs to be considered for the Feasibility phase.
By setting up such KPIs, program management can clearly align a company's charter with their project selection process. e.g. You can dictate that only projects with High Strategic Alignment and at least a specified potential revenue in first 2 years, can move beyond the Feasibility phase. Note that a company's objectives and hence KPIs may change over a period of time, but the key here is to setup the right KPIs and drive project selection to reflect the company's charter. Program management can leverage PPM by attaching the charter or review document to every Gate in the project to ensure that all stakeholders are aware of the company's charter.
Using KPIs, senior management can provide executives with evidence that projects that fit the company's charter were prioritized and executed upon. Again, in the PPM system, this would be a custom report created using an Advanced Search based on various KPI values. E.g. list the current status of all projects with high strategic alignment and potential revenue greater than atleast a certain specified amount. Evidence of adherence to company charter can be shown when all past projects on this list have been completed successfully and all future projects are progressing as planned.
Hopefully, this blog post provides some insight into using KPIs successfully to realize the true potential of Agile PPM.
I welcome your comments and will try to address them here.