Our Development Methodology is just one thing more that makes us better
Microsoft CRM 2011 consultants can be found everywhere. Every MSCRM vendor website you see claims ‘we’re different’ and provide a handful of business clichés to validate the claim. At dynamics four, our development methodology really is different and we are the only Microsoft Dynamics® CRM consultancy that can back up our claim. We’re the only Microsoft Dynamics CRM vendor that not only has a development methodology, but publishes it.

We actually have a development methodology
Ask around and you’ll see that delivery problems on Dynamics CRM projects are very common. If there’s heavy customization that involves development, you can almost bank on the fact the project is over budget and late. In large part, we believe it’s because most vendors treat CRM Development as though it’s unique creature. It’s NOT. Successful software development efforts share many common characteristics, so do failures. Having a firm development methodology and following it, coupled with A-list developers is one of the things that goes into a successful project. Here are a few others:

Design Matters
While Microsoft CRM projects are different from traditional .NET projects in many ways, there’s more that’s common than is different. Many companies overuse custom entities because they lack the knowledge of existing CRM entities. Others rely too much on out of the box entities because that’s all they know. Every dynamics four development project starts with in-depth discussions about optimal entity structure.

Prototyping
There is no magic structure that’s right for every situation, so we rely heavily on prototypes. We engage with our clients to find out the expected user volume and data load. Then we multiply and multiply some more. Each prototype is tested not just with the maximum number of records the client anticipates, we use at least an order of magnitude more data. Then we use advanced Stress Testing tools to make sure that the application remains responsive. It’s one thing to claim “we have a well thought out entity model”, it’s something completely different to stress test the design with an order of magnitude more data. Instead of making empty promises about the application being responsive, we provide detailed metrics, up front, about data volume and response times.

Use Cases
One complaint every heavy CRM user has made is “It’s too clicky” or that it can be time consuming to do seemingly simple tasks. Extra clicks equate to extra time. Extra time equates to reduced productivity. All of this adds up to more money and later delivery windows.  We know how much time matters and even the best functional application isn’t of much benefit if it takes too long to get something done. We incorporate Use Cases extensively based on client feedback so we can tell you with precision, how many clicks it takes to do something and how long it takes to do it. Make no mistake about it, if actual Use Cases aren’t used with realistic data loads, your vendor is guessing and leaving the success of your business to chance. The development environment needs to closely track to production. Every Use Case is responsive with only a handful of records in it. Trying the same Use Case with a few million is a different story altogether.
Having a firm commitment, up front, on what loads can be supported and what response times will actually be to perform a start to finish action lets users know exactly what they’re getting. It also allows us to identify problems as early in the development process as possible, when it’s still easy to fix. Instead of telling you “It works”, we tell you “It works exactly as promised, and it takes x seconds and y clicks on the low side, a seconds and b clicks on the high side.” This means quantifiable results instead of what too many other vendors provide: excuses, blaming it on the product or telling you to buy more and expensive hardware upgrades.

UML
Homes, buildings and skyscrapers aren’t built from verbose Word documents, meaningless PowerPoint presentations, incomprehensible Visio diagrams or really detailed Project plans. Builders and clients don’t have arguments like “You said the living room would be big, this living room isn’t big.” Yet such arguments and unmet expectations are inevitable, absent a precise mechanism to avoid such confusion.  Take any non-trivial document and have five people read it. See if all five people essentially agree on what the document said, let alone can find 100% agreement on it. Chances are it won’t happen. And let’s face it, non-trivial projects don’t just involve five people, they usually involve quite a few more.
We’ve all played Telephone back in 2nd grade and saw how badly things get distorted. Yet Telephone is the predominant design methodology for too many CRM Projects.  Not at dynamics four. Instead, we use Unified Modelling Language (UML), software engineering’s blueprinting document. A UML diagram means the exact same thing to 5 people or 100 people. It means the same thing in Alabama, New Delhi, Moscow or Singapore. It allows software to be designed with complete precision, leaving little to chance or the imagination.  Unfortunately, if you search around, you’ll see most every developer nowadays claims to know UML. Only a small fraction know it well enough to field even the most basic interview questions. At dynamics four, ALL of our developers are fluent in UML (and we’ll gladly have you test us on it pre-engagement if you have any doubts). It’s the only design language we speak. Sure, we translate it into plain language for the non-technical stakeholders, but all of our technical people live and breathe UML. Others talk about it (although it’s a rarity to find a CRM vendor that uses blueprinting of any sort, let alone UML), we live it.

Agile, Microsoft Solution Framework (MSF), Waterfall
We adjust to our client’s demands when it comes to process methodology. We can, precisely because we actually know all of the major methodologies. Everyone from our business analysts to project managers to developers know Agile, MSF and Waterfall and we know them well. Whichever you prefer, we’ll accommodate you and we’ll do it well.

We do some things for all projects:

  • We have dedicated build servers and environments for every single client engagement. You want to see how things are going? You don’t need to take our word for it. Just log into your environment with your credentials and see for yourself.  When a feature release date arrives, you can log into your environment and see for yourself that it’s done.  Some vendors won’t let you see the work as it’s being done using lame excuses like “It’s not finished”.  We do what we say so we have no fear of you calling us on it, in fact we encourage it.  Come on in, take a look, and see your product as its being built.  Verify that it’s doing what we said it will. Verify for yourself that the number of clicks is what we say it is. Verify for yourself that our structure supports ten million records and still responds in under 3 seconds.  We know many people have been burned by empty promises (many times ones made with the best of intentions).  And most importantly, if something changes midstream, we have the ability to adapt and change (now, depending on the contract it might involve a change request) but you’ll get to see the application being built every step of the way.  This means no unmet expectations are set, and promises are kept.  We understand that you may not have perfect vision about the project up front, letting you see it as it materializes lets you make sure you get what you want and more importantly, that you get the most value for your money.

  • If you are looking at another vendor, ask them about their testing process. We have daily drops and smoke test drills. We make sure every single day that nothing we did broke anything we already did. We make sure new code always works well with existing code. And if there’s a problem, we’ll know about it immediately. Quality development shops shoot for 100% code coverage with unit testing, well, we find that number insultingly low and rest assured, 100% code coverage is the floor beneath which we won’t tolerate, not a goal we strive toward.  And our test reports are updated constantly throughout the day.  You want to see what our failure rate is, log into our SharePoint site and see for yourself.  Our reports are generated twice a day at a minimum and can they can be automatically e-mailed to you if you desire. If a vendor doesn’t do automated testing, they aren’t really testing your application. It simply takes too long to do a full walk through of an application each day if you do it manually. And if they aren’t full testing it, you’re in for some bad surprises, we guarantee it. No one is ever that consistently lucky. With dynamics four, luck has nothing to do with, it’s intentional.

  • In line with our automated unit tests, we automate stress testing as well.  We make sure everything we do continues to support the metrics we promise. And we verify it several times each day. And we post those results to your customer site every time we take a snapshot of them. They’re there for you to see (and we can automatically e-mail them to you if you like) every day and if you see something you don’t like, we can have a discussion about it immediately, well before it ever becomes a problem.  

  • As stated earlier, you can log in at any time and see your product being built. No client has ever paid someone to tell them “it works on my machine”. No one ever pays a vendor to tell them ‘it can’t be done’, after all ‘not being able to do it’ should be free.  It needs to work on your machines, in your production environment. We automate our deployments daily. This allows us to run our tests and do our verifications on a regular basis. If there’s a firewall issue, we’ll know immediately. If there’s a collision with solution versioning, we’ll know immediately (yes, we actually version our solutions meticulously, documenting major, minor and full releases) and it is OUR PROBLEM and we own it. We see problems and verify success immediately, and that allows us to take corrective action, IMMEDIATELY. We’ve heard of too many projects that were shining stars all through the development process on the development machines, only to fail completely when the time came to move to production. To date, every single one of our production drops has happened on time, seamlessly and in most cases, we get them deployed early. When’s the last time you had a vendor tell you they could do that at all, let alone do it consistently? When’s the last time you had a vendor actually promise that as part of the engagement?

  • While we automate everything we do, some things just need a human eye.  Computers are really good at computing large numbers, but they’re really bad at other tasks (if you don’t believe us, try writing a program that differentiates between a dog and a cat, something any two year old has mastered). Our Business Analysts and Testers work with yours to make sure that things work exactly as advertised, and we are constantly collecting statistics to verify it.  But some things need a human touch and we make sure there’s no shortage of such oversight as well.  In fact, we’re so confident in our process, we let you see it for yourself as we go along (sure, we mentioned that repeatedly, but we’re proud of it).