Moving Beyond the “Napkin” Plan
With your Napkin Plan starting to grow and fill out, and timelines coming together, it makes sense to begin formalizing all of this into the SAP Project Plan (if you have not already done so). Throughout this book, I reference what I mentioned earlier—the SIPP, or SAP Implementation Project Plan. A copy of a sample SIPP may be found on the Planning CD.
How to Begin Measuring Progress and Success
Tracking, measuring, and charting progress is all accomplished via the SIPP. It is the Project Plan that becomes the central vehicle for tracking changes to the plan of record, too. That is, as newer versions of the SIPP emerge (due to inevitable delays, the impact of authorized “scope creep,” changes or challenges with regard to staffing, and so on), the old project plans serve as documented point-in-time project snapshots.
To help keep the SIPP up to date, my team and I recommend daily, focused 30-minute daily tasks project-team meetings, and comprehensive weekly status update meetings. The daily meetings are best hosted in the morning, that is, 7:30–8:00 a.m. or sooner, and the weekly meetings seem most effective Monday mornings (replacing the daily meeting) from 7:30–9:00. These times tend to work well for a number of reasons:
The project team is “fresh.”
It tends to force individuals to show up (whether in person or via conference call) on time.
In the case of global implementations, mornings throughout much of North America allow for Europe to attend the meeting/conference call as well.
It leaves a contiguous block of time—the rest of the day—for work to proceed uninterrupted by status meetings.
To keep the meeting moving along, one of my colleagues likes to hold his daily meetings in conference rooms without chairs. Others leverage a regular daily and weekly format, or a running list of “minutes” and action items from the previous meeting, to stay focused. Chit-chat is frowned upon in all cases until after the meeting is wrapped up.
Evenings are generally bad times for meetings, as the project team will often be “in the middle” of something late in the day, and their time is best spent focused on the task at hand rather than breaking away for 30 minutes at the risk of losing momentum. Fridays tend to be bad for meetings for the same reason, regardless of how tempting it might be to the Steering Committee or Project Sponsor to have an update before the weekend starts.
The key is to remain flexible, though. For example, one client of ours started with daily meetings and then made a change mid-way through the project. Instead, they hosted their daily meetings Monday, Wednesday, and Friday during lunch, and were quite successful. Why? Because they brought in lunch, and stretched the meeting to an hour. In this way, everyone not only had a chance to share status updates, but everyone had enough time to eat (for free!) as well.
Another client chose to implement meetings from 4:00–4:30 p.m. each day. This time slot was met with grumbling initially, but within a few weeks it became “business as usual” to meet during this time period. It worked for them—they got in and out, with little apparent interruption to the real work of implementing SAP.
Maintaining the High-Level Project Plan
Now that you are in a position to measure progress, track successes, gather updates, and so on, you can begin to effectively maintain your formal (albeit still high level at this point) project plan. Key milestones inherent to all SAP implementations have already been documented in the SIPP. For example, all SAP projects require a development and a production environment, each of which must be designed, purchased, installed, configured, optimized, and deployed. And all SAP projects must take into account a client strategy, a cut-over strategy, and address things like performing the Basis installs, stocking the new systems with data, testing the new business processes in terms of integration with other business processes, and so on.
Additional tasks will become more clear as we move through the next few chapters. For instance, the system landscape requirements of the specific implementation will become apparent, as will timelines for the various implementation tasks to be executed, and much more. We will continue to fill in some of the project plan “holes” that exist with regard to your specific implementation as we move through each chapter together.