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.