You just stopped and stared at that little set of checkboxes near the top of the new weekly status report you’ve just been handed.
Project Phase:
□ Requirements
□ Design
□ Construction
□ Test
□ Deploy
“Well,” you say to yourself, “that depends.”
The new development servers have been deployed, but we haven’t even begun to lay out the requirements for the new production hardware. We’re halfway through our first move-to-production pass on the technical upgrade, and next week we’ll begin our fit-gap sessions for revamping the payroll configuration and customizations. So let’s see – we’ve deployed one piece, but we’re in design/construction/test for one piece and in requirements for yet another. What happens if I check all the boxes? Well, we’re about a quarter of the way through the budget, so let’s just call it…design!
Then you ask yourself: how can I be following the PMO’s waterfall methodology if I have more than one project phase in play? Oh, it’s a “modified” waterfall. That’s it. Overlapping phases. And just when is your next phase review? And those move-to-production passes – we’re doing several of these, refining and testing the scripts as we go along, right? So, isn’t that kind of, er, iterative? And that draft list of customizations that need re-tooling – it’s looking very scrum-like – almost like a sprint backlog. What’s up with that? We’re not Agile, are we?” What is this: multiple phases, multiple methodologies? Just how many projects am I working on here?
Which brings us to an interesting question: Is your ERP upgrade a project or a program?
How do we tell the difference? And why do we care?
Roy Youngman, in a blog post entitled, Programs are More than Just Big Projects, at 0 to 60 in 1.6 Gigaseconds says that differentiating between a Program and a Project is crucial for companies that want to realize value from IT investments, because they need to be managed differently. While many believe that a program is just a Big Project, Youngman defines a program as, “the unit of management for conceptualizing and ultimately achieving the desired outcomes of a major strategic initiative. A Program usually eventually encompasses multiple projects and lasts for long periods of time.”
“A Project,” he says, “is the unit of work for creating a specific, predictable deliverable. A Project is a Project when Project managers clearly understand why the project exists (its objectives), what is to be delivered by the project (its deliverables) and have the knowledge and ability to accurately estimate how the deliverables will be produced and the resources required to get the job done (the work-plan).”
Many ERP upgrade projects are often billed as – or linked to – strategic initiatives, lasting a year or more and involving dozens of resources. Because of their cost, complexity, and challenges to completion, there’s a tendency to put them off until absolutely required.
When a project does get off the ground, the scope likely includes more than just a technical upgrade. New infrastructure supporting the development and test environments, as well as a high-availability production environment may need to be established. Additional modules to provide business value, like employee and manager self-service may be included as a critical component of the business case.
Because of enhancements to the delivered processes and user interface, change management activities – including business process redesign and user training – become a critical success factor. These changes may drive a revamp of batch processing, report distribution and application security may be required as well.
So what’s a project manager to do? Many organizations have made significant progress to get to a Level 3 maturity model, and have an established project and program management discipline. If your project is really a program, you may know more about the business value and interdependencies involved, and this information should be should be shared with the portfolio manager and the PMO. If you’re still managing multiple projects, make a special effort to fashion your project and resource plans to be predictable. Design your controls and reporting as needed to take into account multiple sub-projects.
Amy Alberg, blogging at Making Things Happen, says to consider utilizing program manager skills that are outward focused, and to rely more on your influence in the organization. Learn to get comfortable with the ambiguity that comes with a program; think and act strategically. Be aware that programs require an even more sophisticated approach to managing change and navigating politics than projects.
Youngman suggests this: “Projects should be structured to form, execute, and disband in highly defined periods of time (months, not years) while requiring a small number of identified resources (a few, not dozens). A Project that takes multiple years and dozens of resources is not a predictable construct.” Work with your director, business and IT stakeholders, and the PMO to structure your sub-projects to be predictable.
“Projects that are predictable improve the health of the enterprise in several ways,” says Youngman. “First, accountability for execution is well-established to someone that has the ways and means to be successful (e.g., a Project Manager). Pride-in-workmanship becomes a constant motivator as team members move from one success to another. A virtuous cycle is created that fuels itself as individuals grow through success rather than rationalize failure.”
