In the last year or so, my area became leaders new product development. In a customer-focused company this is essential. This led one of my collogues to bring in the AIPMM product lifecycle framework to guide our work.
Like most frameworks, it is an application of the basic principals of the systems development life cycle (SDLC,) which encapsulates most project management techniques. This got me thinking how these frameworks succeed or fail within organizations.
Generally, it is not the framework that fails. The AIPMM model works like most others following the this pattern:
Plan > Design > Build > Operate/Refine/Retire
In business, there are is actually three outside forces that have a greater effect on project outcomes. People using any framework need to understand them in order to succeed.
A strategy does two important things for frameworks:
It defines what ideas employees will research at the beginning of a project. Without a strategy ideas and the project scope are impossible to vet accurately. This leads to indecision and project bloat.
It allows people to make decisions between phases (at tollgates.) Without a strategy, decisions are made based on who pitched the idea. Bad projects result because there is no vetting process.
Empowered decision makers
The product lifecycle framework has gates between phases to let workers and stakeholders gauge the viability of a project. During these checkpoints, decision makers need the power to kill the project. Why should they have this ability?
Usually, management personnel pitch projects they are have a interested in. Then hand it off to subordinates to execute. Because it is hard to say no to the boss, employees tend to finish projects once they receive orders. Unless management trusts their judgment (the definition of empowerment) bad projects are hard to stop. I have seen too many unnecessary projects built because management gave employees the responsibility to build, but not the authority to direct its design or kill the project.
Adherence to the framework
This might sound like a no brainer, but often groups start off with good intentions on using a framework and veer off after a few months. It is easy to do because frameworks impose constraints and may slow implementations. This tends to be an anathema to executives who want it built now. The project lead has an important job to educate others on why they should follow the framework. In the end the project is likelier to succeed and meet the needs of the organization.
Remember the adage: One is better than none. Even if they are a pain, always work within some sort of framework to help guide and improve decision making. If the one chosen doesn’t work out, there are plenty of other to choose from.