Microsoft Dynamics Partners Approaching Microsoft Dynamics Projects (a Hidden Core Value in Successful Projects)

Projects are inherently risky things. There are lofty goals that need to be achieved in the context of the triple constraint of scope, budget, and fixed periods of time.

Or are there only three constraints?

While these triple constraints give limitations to any Microsoft Dynamics project there is a larger unmentioned constraint, a fourth that ultimately becomes the ultimate measure of any Microsoft Dynamics CRM or ERP project; namely customer expectations.

Welcome to the constraint you always knew was there.

Over the years, many have worked to improve on traditional project methodologies. Traditional meaning what many call “waterfall project management”.

Pure “waterfall project management” focusses on completing one stage of development before moving to the next stage.

Agile project methodologies have sought to bring in different approaches though. While many refer to agile project methodologies as “new” there have been individuals trying to introduce “agile methodologies” over the years dating back to individuals such as Walter Sherwat’s “Plan-Do-Study-Act” method (in 1930). Ah yes, 1930?

Agile project management encompasses explicitly four critical core values that many feel have not been utilized properly in roll-outs of projects and put emphasis on these items.

We’ll review these four core values and how they add value to projects and then explore how a critical but not overtly mentioned principle plays a critical role in developing fast to market Microsoft Dynamics implementations.

 

Core Value #1: Ensuring You Value Individuals Over the Process and Tools During Your Microsoft Dynamics Implementation

The first core value emphasizes that importance of keeping the focus on solving the problems at hand; even to the removal of processes and tools in your Microsoft Dynamics implementation.

Problems are not solved by following a process.

By focussing on items such as having real “in-person” conversations (specifically face-to-face conversations) we get much faster to solving problems.

This serves as an ear-shot warning to every Generation X or Y consultant to – “pick up the phone”.

While it might be common not make site visits all the time for an consulting engagement at minimum it’s important to discuss the issue over the phone.

You might verify what was discussed in your conversation over email but to try and solve problems over lengthy email conversations goes against every wisdom in the book. And in this case, what is considered best practices in agile project management.

To many this might seem common sense. Or maybe not?

This also harks us to the point that if we are going to use our development teams to interact with our clients we have to make sure that our development skills have soft skills.

We don’t allow our consultants to bury themselves behind a computer without having conversations with the customer.

And even vice versa, we don’t allow the customer to bury themselves behind the computer.

Not only do we need to speak every now and then, but rather – frequently and often. Frequently verifying each other’s understanding of the requirements.

When this type of conversation is encouraged – trust is developed.

These types of conversations help determine the true root reason around why something is an issue. We can then use a tool like the “six sigma” approach of the “five why’s” to address the root around why something is an issue.

Any type of conversation like this would be extremely difficult to do over an email conversation. You would be lucky to not just address the surface issue.

 

Core Value #2: Working Software Over Comprehensive Documentation in Microsoft Dynamics Implementations

Ultimately, working software, or more specifically a working product is the ultimate goal.

If the constraints of budget, time, and quality come into too much focus without thinking strategically around the ultimate goal we get stuck on the way to our ultimate destination.

With efficiency, productivity and ultimate goal of a working product in mind; we look at taking the approach along the lines of providing documentation that is “barely sufficient”.

Similar to an 80/20 rule of productivity.

Like we applied the “five why’s” to finding the root reason of how an issue needed to be addressed, we can also use something like the “five why’s” to ask why documentation needs to be provided.

We look to address the root reason for documentation in the quickest way possible. Ask yourself:

• Is a communications plan really necessary?
• What is the minimal amount of effort needed to be put into a project schedule in order to report the KPIs we need to run the project?
• How can we focus the status reports on action items instead of historical data that really has little bearing on the practically of the project moving forward?

 

Core Value #3: Customer Collaboration Over Software Negotiation in Microsoft Dynamics Implementations

The customer is not the enemy. No seriously, let me say that again, the customer is not the enemy.

We used to have a slogan at that said “human touch”.

It was a reminder that we were focussed on being one team and bringing a relationship together with our technical expertise to any project we were a part of.

One of the difficulties in driving collaboration and teamwork in any project is the inherent negotiations that need to occur:

• at the start of the project
• scope changes in the project
• at the end of the projects

Although we often try to avoid changes, it’s important to recognize for all team members that there will be changes and become aware that not all the requirements have been uncovered and won’t ultimately until you’ve finished the project.

Recognizing that there will be many changes during the life of a project helps diminish the emphasis on deep contract negotiations and rather put the focus on working together.

 

Core Value #4: Responding to Change Over Following a Plan in Microsoft Dynamics Implementations

Change in us all inherently is the process to make us better. The same with products. Change inherently improves the product and is something to be embraced.

The difficulty is not change itself but uncontrolled change and more specifically “un-prioritized change” (I don’t think that’s actually a word but I like it).

Like anything else in life, there are a million great things to do but we don’t have time for them all.

The important thing is to do the “important things”.

Great changes are also inherently linked to listening.

It’s estimated in a few years that 80% of all products will be crowd sourced; meaning many requirements for the products will inherently come from the shareholders or the customers themselves.

With technology evolving and giving us the opportunity to better listen to our customers expectations; we have the ability to change products to provide a more natural fit.

The important thing is that expectations are set that change can be an opportunity as a big win for the customer and not just a difficulty.

The Microsoft Dynamics platforms allow organizations to stand to gain large strategic competitive advantages because of their ability to easily adapt and change.

 

The Underlying Principle That’s Never Mentioned That Underpins All These Values in a Successful Microsoft Dynamics Implementation

With the removal and minimization of processes, tools, documentation and items such as contract negotiations there’s an underlying principle in more agile Microsoft Dynamics implementations (or any type of implementation for that matter) that’s not mentioned.

There needs to be an underlying principle of trust more then ever.

Any type of roll-out with “less supervision” needs to be based on the underlying principle of trust and integrity on both parties.

There is a deep assumption that:

• you trust the various skills of the teams
• that there is integrity of the team in their conversations
• that every individual in the team has inherent good intentions for the other party

It is this type of trust that allows us to put away many of the inefficient tools and processes that are often associated with project management and assume a more efficient and minimalistic approach.

It’s well documented that trust in an organization dramatically increases the efficiency of the organization (see Speed of Trust book).

Trust eliminates what we call a “lack of trust tax”. A inefficiency tax of 10%, 20%, or 30% (whatever it may be) that’s required when individuals don’t trust each other.

Trust eliminates the need for everyone needing to make sure they have their bases covered and providing extensive documentation to ensure that “they’re covered” (there are benefits documentation such as the benefit of clarity in communication).

It’s the same way in developing projects, when there is an inherent trust in the team members, projects can be dramatically accelerated and much overhead eliminated.

Doing projects in smaller steps also can help that trust accelerate (rather then doing extensive documentation beforehand) because it provides both parties the opportunity to prove that they are trustworthy to each other.

While there are “12 principles” in agile project management methodology often mentioned – there is another one that is critical to these types of environments that accelerates trust.

All parties need to evaluate on a constant basis the principle “what’s best for the other party involved”.

The more individuals follow that principle the faster and more efficient the project will run. The more projects will be accelerated.