Our friends at MSDynamicsWorld.com recently took note of some tips provided by a product manager to a major bank on how to manage their Microsoft Dynamics implementation. They’re applicable to a wide range of IT system implementations, so we’ll reprise their thinking in today’s post. The full text is available here.
- Develop a “long view” strategic roadmap. “Our roadmap is about twelve to eighteen months out and it’s our high-level priorities for our system and our application,” said the product manager heading up the project. “Having a long-term view is going to allow you to set milestones for your team. It will give you a baseline to measure yourself against. Priorities change all the time, but at least if you have a baseline and you broke down what you thought you wanted to do, you can use that to measure yourself against later.”
- Actively manage change. Managing change with regard to a system like Dynamics means planning for flexibility and understanding which changes are important enough to require new releases. “Our environment is very locked down. We are not allowed to make changes on the fly,” said the presenter. Furthermore, making changes could impact the downstream partners if they are not prepared and coordinated. Analysis of the impact of changes helps you understand which are highest priorities and which should be delayed.
- Create a development backlog. The next step is creating a development backlog to manage changes requiring development. “Think about it like a big bucket of all the changes you want to make to your environment at some point – and for us it means requiring development at some point,” she says. “Our backlog includes the large roadmap items and those sit in the backlog next to small enhancements and also defects. Everything goes on one long list because if the development team has to work on it, it really only works when we work off one list. You just need to create the list with a tool that everyone has access to” (for example, as we’ve found at PSSI, SharePoint or Asana).
- Prioritize and “groom” the backlog. Agile software developers do not prioritize by first-in, first-out; they approach their backlogs daily, prioritizing based on customer requests, bottlenecks, development capacity and so forth. You probably needn’t meet in a daily stand-up meeting as developers do (or three times weekly as we do at PSSI), but still, be prepared to prioritize and groom the backlog, adding and subtracting items on the list and changing priorities as they arise.
- Plan the release. The next step is to plan the release, including estimating and “spending” development capacity. “We pick all the candidates for our release based on priorities, in a nice, ranked order. You just take the first 20 or 30 items off the top of the backlog – which should include all the candidates for the release,” she says. “Then we go through each item, one by one, and talk about the requirements for each of our items in the backlog with the development team and the testing team.”
- Release changes to users. Finally, when you get through the development process and QA and you get ready to release it, tell your users about the changes. “We do three things with each release. We do a release email briefly describing the key changes. Then we hold training calls and we record them and post them out on the SharePoint site for the people that couldn’t make the calls. We also post some reference guides and some quick online demos on a SharePoint site.”