A project manager needs to have a fifty-thousand foot view of all the moving parts on the project, and also be ready to get into the details where necessary. The project managers who can zoom in and zoom out are more successful than others. Those who are unable to do this fall into the following categories and their kind of behavior leads to project failure:
Project managers who stay at too high a level and don't get into (or don't understand) details fail, because they don't have a sense of what is going on at the ground level of the project. These PMs can't assess the issues and fail to take corrective actions in time. Hence, the project fails.
On other hand, there are project managers who come from a technical or consultant background, and often fall back into their comfort zone down in the details. PMs that don't look up out of the weeds will not only get in their team's way (affecting their morale), but will miss the unfolding bigger picture. In such a scenario, nobody has that fifty-thousand foot view, and the rest of the project team keeps running with no clear direction, leading to project failure.
In the following sections, we will cover the activities and deliverables that are important for project governance.
Your project plan is a roadmap of the project outlining the things to be done, when they will be done, and by whom. When developing your project plan for the Dynamics AX implementation, the following details should be covered:
Decide on a phased rollout over the big bang, and define your work-breakdown structure accordingly.
Identify external dependencies as specific tasks in your plan. For example:
EDI testing with customers or vendors
Credit card processors
Dealing with the banks
Any other third-party providers
ISV solutions
Any other business project/projects that would impact the ERP rollout, such as a warehouse move, a new retail store, and so on
Put together all the constraints on the plan—resource/holidays/any blackout dates for release (for example, you should avoid a major release for a retailer close to Thanksgiving or any other busy holiday season).
Define the frequency for updating and publishing the project plan. Keep all the stakeholders posted with the updated plan and upcoming activities, activities that are behind schedule, and the plan for catching up.
Setting up your communication plan at the beginning of the project and reviewing it in the kickoff meeting is important for keeping the stakeholders engaged with the project. The following are some key components of communication management on any project:
Weekly status report: It's extremely important to publish status reports with an accurate summary of the project every week. Utilize this as a tool to get attention from the sponsors for help. Share any bad news sooner and take corrective action. Sitting on the bad news is only going to make it worse.
Steering committee meetings: Schedule them frequently to keep the executive stakeholders engaged. Engaging the stakeholders will help you clear the roadblocks and steer the decisions throughout the journey. Otherwise, they will be on your back when things are not going well and the budget has been burnt. You want them to be engaged when you want and not when have to. At the beginning of the project, you should work with the steering committee to set a timetable for the meetings, the format of the meetings, and the ways in which critical path issues and risks will be debated and resolutions defined.
Meetings on the milestone closure: You can align the steering committee meetings to every important milestone. However, it becomes difficult to reschedule with any changes in the plan. You need to truly complete the milestones. Otherwise, you will end up carrying debt from the previous milestone into the next one. High debt means high risk to the project. Remember, you are not the government—keep your debt in control.
Issue log tracking: Define a tool and a process for managing your issue log, and train the entire team on the process. Actively manage and publish the issue log with the due dates and owners from the beginning of the project.
Scheduling (effective) meetings: Each meeting should have an agenda outlining the purpose or objective of the meeting, the high-level topics to be discussed with the assigned owners, and the time allotted for each topic. Try to have more frequent, but short meetings rather than long ones. Keep control over your meetings; ensure that they do not deviate from the topic, and don't let others derail your meetings. Keep the number of attendees to the meeting to the minimum—invite only those who are required to take the decisions at hand or those who need to be part of the project updates. This will keep the meeting under control. Use quick meetings to brief the team about project updates: even if you have sent e-mails, it does not mean that the message has been received; e-mails are the worst form of communication. The meeting minutes should be published after each meeting and should be brief, documenting the decisions and actions only.
Use of distribution list: Set up e-mail distribution lists for communication/updates related to the project. You may need multiple lists (project committee, SME's, technical teams, and so on) that will allow you to communicate with the relevant audience.
The stakeholders don't give you an open check book. To stay on track, you need to watch out for paths derailing your project, and manage them with a clearly defined change-control process.
Set up a process for change request management, including the process for approval or rejection. Multiple levels of approval may not be a bad idea (for example, approval for estimation, approval for implementation, and so on).
Very often, the change itself may not be big, but its impact on the overall project may be huge. The impact on the testing and training aspects need to be evaluated carefully in addition to actual design and development. Include all the components in your estimation template.
The timing of change is very crucial! I had a situation where the users wanted to change the sequence of the columns on the forms. Suggestions started coming in towards the end of the UAT. The changes that were requested would not have taken too much time had we received this feedback in the earlier rounds of UAT. However, allowing the changes to be made would've encouraged the rest of the business groups to come up with similar requests, would've required updates to the training material, and so on. We had to cleverly push back and add them to the business transformation list. These changes were made after the release, and by then, the business had learnt a lot more about the system and were able to provide better inputs on what they needed.
Your solution architects are going to play a key role in supporting you in your decision to take on or push back the change request. Leverage them to help push back on the requests that do not add value.
Sometimes, you may be in a tough spot when the business asks for changes. For the business it may be small change, but they can't envisage the big picture and the impact of the change on the project. Leverage the steering committee and present the cost/schedule impact.
You have a long way to go on the project, and you should make sure that you have enough fuel for the long ride. You can't wait till the end of your journey to check the fuel gauge; you would definitely run out of fuel.
Keep a close watch on the planned budget to the actual, compare your projected burn rate, actual burn along with the projected earn, and actual earn.
Make adjustments sooner—whether it's getting an additional budget or resource changes.
Watch out for scope-creep items that were not initially planned (you don't want your project to be derailed if the person signing the check hasn't asked for it).
Timesheets and invoice reviews are critical to managing your budget:
Carefully review your spend from the beginning, and understand where time is being spent. If there are not enough details in the timesheets, ask questions! It is like reviewing your credit card statement.
Compare your initial projections of burn with what has been delivered.
Follow up on payments/collections: Timely payments by the customer show that they value the work you are doing for them. When there are delays in payment, most likely there is a problem with the delivery, and the sooner you address it, the more likely you are to put the project back on track.
As part of that fifty-thousand foot view of the ERP project, the project manager has to look out on the horizon for any outside factors that could impact the project. Here are some examples of things to be aware of for keeping your project on track:
Use the latest service packs and cumulative updates for Microsoft Dynamics AX application, kernel, and SQL. Get them installed (have them on the project plan too) as soon as they are available. It will reduce your exposure to the issues that may exist in the standard product, and sometimes, provide an additional functionality that can be used by the business.
Keep an eye out for upgrades or changes that are in the works for any ISV solutions that are part of your project or for any integration partners. Also make sure that the ISV solutions are updated to the latest cumulative updates.
Be aware of other, competing projects that are in process at the organization, and of any pending projects that may be waiting in the wings. These projects could dilute your customer's focus and cause delays. Make sure that these potential conflicts are brought up in your steering committee meetings as a potential risk.
Major changes to the customer's business environment: major customer losses or gains, raw material pricing changes, and an industry shakeup are all examples of external forces that can impact your project. Keeping a lookout for these potential risks will allow you to react and respond more quickly to them.