Getting your project started requires a well-defined project methodology and a strong project manager. This chapter goes over some essential elements for getting your project set up for success.
In this chapter, we will cover the following topics:
Project management and governance
Microsoft provides Sure Step and Lifecycle Services as the methodology for implementing their enterprise-level software. While we will reference a few Sure Step and LCS tools, principles, and documents, this is not a book on How to Use Sure Step or LCS.
Prepare for a great start! Projects don't fail at the end; they fail when they start. Under this topic, we will learn how to prepare for the start of a project, which includes resource planning, understanding expectations and the commitments made, and engaging the stakeholders.
To be successful, you need to understand the commitments made on your behalf by the sales team, and have access to the scope that the customer has signed off on. Additionally, at a high level, the project managers need to communicate these expectations to the entire team, consultants, and the customer team members alike. The following are some points to keep in mind for managing these expectations effectively:
Schedule meetings with the sales and presales teams for knowledge transfer to the rest of the resources assigned to the project; ideally, the project managers should meet the main decision makers while the deal is being finalized.
Document all the knowledge transfer items; you will need them for future reference and to bring the rest of the team members on board.
Get all the documents related to the requirements that the sales team may have received, and have them uploaded on SharePoint (I will be referring to SharePoint often; as for most projects, you would be using it for as a common repository of documents).
Understand the solution blueprint that was put together by the presales team, including any custom or ISV solutions that were shown as part of the solution during presales.
Understand all the documented scope and the undocumented expectations that were set with the client.
Understand the statement of work in detail. Get a good idea of what is in and out of scope, and clarify any vague areas.
Understand the key players involved, their roles, their influence in the company/project, and their personalities. Basically, find out who the stakeholders of the project are.
At this stage, everything looks very easy.
The customers engaging on a Dynamics AX implementation should be hands-on and not sit back, waiting for the consultants to swoop in and do all the work. The customers should keep in mind the following tips to be proactive in getting the project off to a good start:
Getting comfortable with your partner: Spend a lot of time working with your counterpart(s) from the implementation partner; learn about their tools, processes, and methodology.
Evaluate your people: Skilled resources play a key role in your success. Spend time early on to evaluate whether the team you have can make it. Waiting too long to pull the plug on the resources is only going to burn your budget and impact the schedule. At the very least, raise your voice and let your partner know that you are concerned. A customer's project lead, with whom I worked in the past, would ask me within a couple of days of having a new resource on board, ''Yogesh, do you think XYZ will make it? It's your call. Otherwise, you are paying for his expenses too''. That project was very successful as the customer was always watching out and was very demanding to get the right resources on the project. Customers pay a premium rate for each resource and deserve to have the right resources to make the project successful.
Resource continuity: It is a long ride and you need to ensure that you have resource continuity for the key resources, from beginning through to the end. Of course, there are unavoidable situations due to which you would have resource changes on the project—that's where the documentation plays a role. However, it does not replace the need to have resource continuity. To keep the good resources engaged for a longer term, be flexible with the onsite/offsite time or look for more local resources. You don't want to burn those resources with crazy travelling and lose them eventually.
Consider engaging an IV&V (Independent Validation And Verification Vendor): ERP implementations are complex, and each mistake could be expensive if not caught early on. Whether it is solution design, not having the right resources or methodology, or pushing back to the business on business processes, you need to catch them soon. Having an independent validator engaged early on would help uncover such issues and reduce the risk on the project.
Every customer is different. Their business model, industry, and organizational culture have a huge impact on the way you run the project. For example, some environments move quickly, and you need to keep up with their speed. On the other hand, if you are doing a project for a public sector organization, you will have to slow down and go with their speed/processes. Some have a more mature IT organization than others (mature in terms of their IT processes, IT team, infrastructure, and so on). You need to understand the environment and the processes, adapt, and adjust.
Engage with your customer early on to finalize the project governance and implementation methodology. Present them with your implementation methodology and align it to their needs.
Understand their methodology wherever applicable. The customer may already have multiple scrum teams with their boards in a backlog tool, like JIRA or the Team Foundation Server. You can't just walk in and announce that from the next day onwards, they will be following this huge MPP project plan. You will be shot even before you are allowed to grab a seat.
No project can be successful without having the right people on your team. You need to have an A team to deliver on the complex project and transform the business for your customer. This goes for both the consulting team members as well as the client team.
Identify the key roles needed on the project. Map the key roles and the individuals, along with their availability. You need a strong solution architect—someone who can see the big picture, a business analyst for each critical area (for example, if it is a retail implementation, you need to have an experienced retail business analyst), a QA lead, and a tech lead at the minimum to survive on the project as a project manager.
Prepare a resource plan for the consulting team, and share it with your management. This is crucial to getting the right people at the right time.
Provide clear guidelines to the customer on what is required of a good team member to be assigned to the project, and what the commitment will be:
The team members must be knowledgeable and respected in their area of responsibility of the project; they must also be empowered to make business decisions on behalf of their organization.
Recommend the customers to shift responsibilities or acquire part time help during the project to free up the best resources. Business decisions should not be made by someone other than the core project team. Doing so could lead to rework, as decisions are usually reversed down the line.
Similar to business, you need to secure the A+ resources from IT to work on the project.
Make sure that the team members understand that the project would be challenging, and demand a lot of their time before they commit. Work with the executives to come up with compensation benefits upon the successful rollout of the project.
In addition to the consulting team and the customer resources, there are potential external resources that need to be considered. For example, if a key requirement is to integrate to a third-party solution, identifying and engaging resources from the solution provider at the start of the project will help keep these integrations from becoming roadblocks down the road. Share the high-level project plan with these resources and include them in your communication plan as well.
Once all the resources have been identified, the project manager must bring them together as a cohesive team. The following are some tips and guidelines to building and maintaining a good, working team:
Define clear responsibilities among the team members and document them in an organization chart. For example, John - accounts receivable, Tom - general ledger, Craig - accounts payable and fixed assets, and so on. Align the customer's resources on the organization chart (internal business analysts, business SMEs, infrastructure, project management, leadership team, and so on). The following diagram shows a sample organization chart:
Start engaging with the team to understand the team assigned to the project and to identify the strong and the weak areas; you need to know who your problem children are so that you can pay more attention to them.
Prepare a resource-onboarding checklist for the project. It should include getting access to the client VPN, environments, SharePoint, adding to the distribution lists, updating the organizational charts, the assignment of the development machines to the developers, any mandatory security trainings, and so on. Identify who to reach out to for initiating these steps. Smooth onboarding will help in making the resources effective as soon as they join the team.
Every resource should have his/her own dedicated account (no sharing of accounts/passwords and no generic accounts like user1, user2, and so on).
Watch out for the upcoming holiday schedules for the different locations where your project team members are based, and plan accordingly. Create a centralized calendar for holidays, and even vacations, for the project team. Update the key milestones and meetings on the project calendar.
Align the internal IT resources/SMEs on the project organization chart prepared by the consulting PM. Ensure that you have good coverage for each area, and start working on filling the gaps through new hires, contractors, or by training the existing staff. This will help in smoother execution of the project, as your internal team will be involved with the decision making for the solutions. The team members will be able to help with the transition as they would already know the solution.
Training the existing staff early on will kill two birds with one stone. Your customer knows the business already, and can add lot of value to the project team (it will also save the consulting dollars). Moreover, it will reduce their anxiety over job security post-implementation of the new system. It is worth the investment.
Provide your project team access to customer source so that your team can go through the training material available there while the project planning is going on.
Create a project in Lifecycle Services and grant access to the relevant project team.
Build ground rules for your project in agreement with all the stakeholders. For example, if an e-mail conversation goes on for more than 10 threads, call for a meeting and close out.
The project kickoff meeting is about setting goals and expectations. At the high level, clearly define and communicate the goals of the implementation and why the dollars are being spent. The following points outline the requirements for a successful kickoff meeting:
Review goals with the key stakeholders and ensure that you have the goals defined in the order of priority.
You may want to create a theme and remind everyone about the goals periodically such as in different milestone meetings. For example, protect the core - the goal is to sell, ship, and invoice the customer. (Everything else is negotiable).
Communicating the goals clearly to the team will help keep everyone on track (and avoid any change requests that are not necessary). The kickoff meeting must convey the following to the entire team:
Project goals and scope
High-level solution overview
Project team structure and roles
Implementation methodology and steps to success
Project communication plan and risk management approach
Change control process
Have all team members attend the kickoff meeting. With teams that are geographically diverse, you should utilize the web-conferencing technology or repeat the meeting for each team.
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:
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
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.
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).
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.
With Agile becoming more and more popular, many customers have adopted it as it allows you to react quickly to changing business needs. In my experience, I have seen Agile ERP projects being more successful than the waterfall method. Every customer has his/her own version of Agile though. Understand the customer's current process, and tweak it to the version that would work for the ERP project. For example, if they are creating all the tasks on the board and physically writing them down, you may want to switch to the electronic format for better collaboration with remote teams.
Plan the tasks 4-6 weeks ahead, and build a backlog of things to be done after the requirements or Gap/Fit sign off.
It is very important to have unified tools and processes across the board.
Generally, there is misconception about Agile; Agile does not mean no documentation. You need to enforce using standard templates for all the deliverables (for example, functional design, technical design, and so on), and do not take any shortcuts using the Agile methodology as an excuse.
Schedule frequent reviews (demos) with the business owners for each sprint cycle.
Break the implementation team into smaller scrum teams by relevant areas. You would have cross-functional dependencies across the teams.
As mentioned at the beginning of the chapter, projects don't fail at the end, they fail when they start. In this chapter, you learned about the things that are essential for a great start of your ERP-implementation journey. We discussed the importance of understanding the customer's expectations, environment, and culture. This was followed by learning how to plan resources and establish a team. You also learned about common project management and governance activities and about deliverables such as project plans, communication plans, change control, and budget tracking. In the end, you were given some recommendations for adapting the Agile implementation methodology and tips for project managers to keep the project on track.
In the next chapter, we will learn about the requirement gathering techniques and Conference Room Pilot (CRP)—early validation for the completeness of your requirements and solution.