By: Alan Earls
Whether project management is driven by proprietary or generic methodologies, Microsoft Dynamics implementers rely on a host of approaches and tools to focus and manage each engagement and ultimately to deliver a working solution.
“I suspect almost every company I have ever talked to wants to implement a vanilla phase one, at least initially,” says Tim Hourigan, partner, consulting, Armanino LLP of San Ramon, Calif. That is true “whether they are coming from QuickBooks and adopting something a little more sophisticated, or coming from [something] super-customized that they believe is too hard to maintain.”
The CEO and the CIO say they are on board with that approach, and everyone believes this will be the one implementation that goes exactly as planned. But as you peel the onion of the project, you discover constraints. Maybe something in a legacy system simply can’t be changed, or you find Salesforce has one way to do it and Dynamics AX does it in a different way. “Inevitably, the answer comes back that it is the new system that needs to adapt,” says Hourigan.
And that’s where the nitty gritty of methods and approaches comes into play. For example, Hourigan says that as a Microsoft partner his organization has leveraged Microsoft Dynamics SureStep as well as agile methodologies and waterfall approaches, “blended together” to deliver results. “Our experience shows it works better that way,” he says, citing the sometimes “too heavy” documentation of SureStep.
Sometimes a more customized approach is needed if, for example, a publicly-traded customer requires Sarbanes-Oxley compliance. In some cases, engagements include more than one application, making it helpful to further customize and adapt project management approaches.
“We also need to respond to client feedback and either trim back or beef up some areas,” he says. “We might want to incorporate agile or scrums, where we could chop a project into smaller pieces – but ERP is so foundational it is probably only in second or third phases of an implementation where that might work.”
In general, though, Hourigan says their approach can be described as “hybrid with a waterfall wrapper” – or an iterative process that mirrors agile. Purists, he notes, would certainly not consider it true agile, but “we still use the scrum concept” as a way to organize and achieve portions of project deliverables. “We have a framework, but it is fluid and people driven,” he added.
Over the waterfall
A general problem, Hourigan notes, is that some clients, especially those schooled in waterfall methodologies or any other similar methodology, “are flabbergasted that there isn’t one, single industry-wide method of conducting an ERP implementation.”
It’s a similar mix of old and new for Jessica Noble, principal, business consulting, at Tampa-based Tribridge, a DXC Technology company. “Having been a program manager and project manager, I have definite opinions; if you were talking about the industry of 10 years ago, it would have been all waterfall,” she says. Today, though, the conventional wisdom in enterprise software today leans toward an approach that is much more iterative and agile-like, with shorter cycles taking sets of requirements into prototyping and validation on a continuous basis. “You are biting off pieces, bringing them live and then refining,” she adds.
A positive of this project style, in her view, is that it gets customers used to the process so they can see what they are working on and watch it come to fruition. “In the old days, with pure waterfall, it took faith on the part of the customer to invest time and then wait for the grand unveiling, not really knowing what it would look like,” she says.
Likewise, with the more modern iterative approach, if there is some mistake in defining requirements you will probably catch them sooner – it isn’t all one massive deliverable where the problems don’t become evident until the very end. For the customer organization, it means change can be more gradual, without the pain and risk associated with a 100 percent changeover all at once. “It’s less traumatic and makes adoption go much more smoothly,” she adds.
Similarly, the iterative style can allow the implementer to get to value sooner – perhaps delivering a key function earlier. The big challenge, though, says Noble, becomes “slicing off the right pieces in the right sequence.” Iterative also presents fewer risks around change, avoiding “scope free-for-all” that can happen when a big, highly-defined project starts to get more scrutiny.
But it’s not just agile. People believe you must be agile, but with packaged software that is impossible, according to Peter Maloof vice president, digital experience and disruption, at Capgemini. “If you have packaged software people are trying to meet a certain scope; true agile considers a troika of scope, time, and resources, with scope as the product of the other two. And then you do sprints,” he explains. Packaged software, in other words, eliminates much of the range that true agile might embrace.
Still, he admits, the reality, is that at least at most Fortune 1000 companies, the client has specific things they need to accomplish. So, Capgemini uses what Maloof calls “hybrid agile.” That entails holding a series of consultative design reviews. “As we get closer to go-live, we get richer details about what the end result ‘looks like.’ Frequently what happens is, we remind them that ‘we heard you say’ this or that, and we can the decide what customization is needed beyond out-of-the-box,” he says.
“It is a way of being agile and still being very deliverable and able to course-correct in a classic waterfall way.”
Maloof makes one more critical point. Flexibility is vital, not just to successfully meet the declared goals of a project, but because the business changes. In today’s economy, six months can be an eternity, and the agile flavor that professional services firms have adopted in varying degrees makes it easier to embrace those new realities, whatever they are.
Furthermore, agility does not mean eliminating traditional guard rails and structures. “People often think of agile as eliminating documentation,” says Maloof. “That might be true in smaller shops, but we build and document so that clients have an audit trail and can see what we did and so that the process and decisions on the project are transparent.”
Elliot Fishman, CEO of Catapult ERP, sees the whole topic a little differently, pointing out that there is “a big difference between project management and [administration].” Thus, in his view, a project administrator deals with a “rear view mirror” perspective: viewing metrics and tasks completed as an indicator of progress. On the other hand, the project manager must focus on the future, rolling hours into budget analysis to get a handle on what’s needed – and available – to complete a project. That can include chasing down individual team members to understand what is progressing and what isn’t and to mobilize resources appropriately. “Their real value comes from understanding; they have to be the person that understands the vision for the project,” taking it from the sales team to delivery, says Fishman.
This critical individual, he continues, must understand the original concept and what was promised, and help translate all of that into a deliverable.
“Every project is based on explicit and implicit assumptions which should be largely documented in a statement of work or project chart. But there are always things that are in some stakeholders’ heads,” he noted. And that’s where the implementer – and the project manager – play their roles.
Next time: What does project success look like?