The goal of Enterprise Performance Management (“EPM”) software is to drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment. However, the competitive environment is hardly predictable and business objectives change based on environmental feedback. As projects are typically linked to business objectives, functional requirements and needs may change even during the project implementation cycle. If business alignment is a primary objective, then the software must be adaptive enough to accommodate the changes in order to maximize value.
Based on the results of a recent survey of IT Software Project Failures, the second highest ranked reason given for project cancellations was too many requirements and scope changes. Project management is often seen as the solution for achieving project success. The traditional approach is predominantly taught and utilized in most organizations. However, this approach has its limitations. The traditional project approach is best used when
· The solution and requirements are clearly defined
· You do not expect too many scope change requests
· Prior EPM knowledge is available in-house
· You can utilize existing templates.
Given the unpredictability within the competitive environment, and the dynamic discovery and delivery processes inherent in an EPM project, a more flexible project approach that allows for changes in scope is required. This flexible approach works best when
· The solution and requirements are only partially known
· There may be functionality that is not yet identified
· There may be a number of scope changes from the customer
· The project is oriented to new product development and/or process improvement
· The development schedule is tight and you can’t afford rework or re-planning.
Although scope changes are necessary evils within an EPM project, too many scope changes without a surrounding process can lead a project to failure. From the view of a business stakeholder, implementing an EPM project is partly getting what you want and partly discovering what you really need. The more transparency obtained, the more likely business stakeholders will attempt to enable discoveries via new or modified requirements. Not having the appropriate boundaries or structure in place can easily lead to exceeded budgets, delayed timelines, and ultimately a solidly implemented solution with not enough business value.
The key components required are adequate levels of flexibility and structure (otherwise known as structured flexibility).
As the diagram represents, structured flexibility provides project stakeholders with a wide range of flexibility to aid the discovery and delivery processes. However, a boundary exists that allows the project to remain structured and meet the project time, budget, scope, and quality objectives. The points where structure meets flexibility should be determined jointly by the project stakeholders. Effective methods should be used to ensure adequate communication within and about the structure. The following seven (7) steps, when used appropriately, can serve as a guide for achieving the structured flexibility that can maximize project value:
- Develop the initial ground rules for maintaining structure at the very start of the project;
- Obtain buy-in for the ground rules from all project stakeholders and modify if necessary to create a common language;
- Ensure all project members are aware that a structure exists and what the protocol for operating within that structure will be;
- Allow project members to be flexible in their thinking and approach;
- Document and prioritize changes and new ideas;
- Focus on the highest value items first (needs not wants); and
- Enforce ground rules where and when flexibility meets structure.
Although these steps may appear simple, high levels of project management and leadership skills are required to implement them. Having an objective project management partner helps.