Over the years I’ve been on projects where there was great project management and others where the project management really stunk! The projects with really good project management generally ran smoother, had less stress, and the project team was generally more productive.
A FEW of the Characteristics of a Well Managed ERP Project
There are a few things that I saw which were consistent with projects that were well managed. In a nutshell they are summed up in the following key points:
- The project manager produces a published project plan with tasks, timelines, deliverables, milestones, and checkpoints.
- The project plan was at sufficient detail to manage the rolled up tasks, but not so detailed that the individual tasks were micromanaged.
- Team leads had individual responsibility at a deliverables level.
- The deliverables were constructed at the detailed task level so that their progress could be reported to the rolled up project task.
- The project manager knew ahead of time what was coming in the next major phase and communicated that to the whole project team ahead of time, and at the transition times to the next phase.
- The “tools” or deliverables templates, resources, and tracking mechanisms were defined AHEAD of time, and then presented to the whole project team with explanations on what information was needed and how to use them as they were needed (JIT or Just In Time).
- Team leads held regular weekly status and progress meetings on deliverables status which was then regularly reported to the project manager and directly tied into the rolled up project tasks.
- There were several scheduled proof of concepts / prototypes / demos of functionality long before a solution went to testing.
This list is fairly generic and can be applied to just about any project. Many, if not all of these items may seem common sense, intuitive, or basic but you would be shocked at how many projects deviate from these basic principles.
SAP Prototyping, Proof of Concepts, Functionality Demonstrations, or Playback Sessions
And that last item, the numerous proof of concept reviews, prototypes, or functionality demonstrations throughout the project were critical. These prototyping sessions were valuable because if they were properly scheduled (early and often) they quickly reveal:
- Consultants who might be better on your competitor’s project(s)
- Areas for genuine business value-add or ROI that might require a scope adjustment but the benefit far outweighed the cost
- Capture and correction of process gaps before integration testing
- Adjustment to process focus through better articulation of business need after “seeing” what functionality is there
- Identification of gaps and risks in application functionality
- Indicates whether your outside project manager is able to coordinate the necessary work-streams to accomplish the proof of concept sessions
- Work through and resolve any early warning signs of performance problems
By insisting that your first proof of concept or prototype session occur right at the end of blueprint you have sufficient time to make any necessary staffing adjustments. Maybe your competitors need some “help” on their projects :)
Warning Signs to Be Aware of In Prototyping
The first warning sign is if a prototyping session or timeline is missed without a clear justification. For example, if the system landscape was not set up in a timely manner to construct the demo or prototype. Unless this was due to procurement, logistics, or security issues outside of the project manager’s control then this should be viewed with suspicion.
If there are SAP or ERP application problems which cause the delay you may want to take a hard look at any consultants who are responsible for installing and maintaining the various software applications.
Another warning sign is if the prototyping sessions are chaotic, disjointed, and generally fouled up experiences. Usually this will fall into two categories, either a) the project manager is not as experienced as you might need, and therefore might be better off working for your competitor(s), or b) the project timeline might be too tight and there is not enough time to do the prototyping in a proper manner. How can you tell the difference?
There are lots of things to consider, but here are a few:
- Is the problem because one key process area is not ready
- Is the dependent process, or process bottleneck too complex for the time frame?
- Would a few more days make a significant difference in the readiness, coordination, and execution of the prototype / demo?
- If only a small time adjustment is needed, and there are obvious or clear results from just a few days, the timeline might be a little too tight
- If a short delay does not produce a significant improvement in the organization of the prototype presentation as well as the fit and finish then you may have a project management or a consultant problem that needs to be addressed
To gain additional insight on this critical stage of the project, especially in the beginning when a properly formed foundation is so critical please see the post entitled “Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results.”