Sustainable Development?

Sustainability is a buzzword in business today, whether talking about maintaining growth or minimizing environmental impact, and seems to be tacked on to a variety of products from cereal bars to cars. So what do I mean when I talk about sustainable development with Microsoft Dynamics GP?


Now, first, I have to add in my own disclaimer. I am not a developer. So I really would love to hear from others on their experiences. But I have been involved in enough functional and technical design processes over the years, that I have seen some themes emerge around customizations that truly increase satisfaction with the software versus those that seem to limit the software’s capabilities and the customer’s satisfaction.

In my mind, sustainable development is custom development that is approached in a way that:

• Enhances the user’s experience with the system, does not diminish it

• Does not try to replace the need for training and time to adjust to a new system

• Uses supported tools and recognized approaches for solving a problem

• Includes documentation, including foresight regarding upgrading and changes in business requirements

Given the robust toolset that we now have to customize Microsoft Dynamics GP, it is not unusual to have some degree of custom development on even the smallest projects. These minor customizations can often reap big rewards in terms of satisfaction with the system. How do we go about developing these customizations in a “sustainable” way?

I think that there are three key principles to keep in mind when considering custom development, to ensure that you are approaching it in a sustainable way:

1. Ask Why? Why is this needed? Is it to support a business process and requirements? Get to the heart of the need, and address it appropriately—which may not be with development. It may be training, it may be the learning curve that comes with a new system, it may be understanding that business requirements can sometimes be differ from an individual user’s perspective.

2. Document the design. Putting it down on paper can make a world of difference in terms of the thought processes applied—thinking through upgradeability, appropriateness of the selected toolset, and flexibility for future requirements. Plus this gives everyone something to respond to, something concrete to reference and consider.

3. Don’t limit yourself. This is a hard one, because we all rely on the tools we know best. But when something falls outside your comfort level, or you sense that there may be a better approach, ask around. Trying to shoehorn the tools you know to meet a need can create a cell you will be forced to live in for years…and years…and years :)

Of course, I am always interested in hearing your perspectives! Please let me know if you agree/disagree or want to add to the list above.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Hi, My Name Is Christina And I Actually LIKE Modifier

It is a universal truth that we people are complainers.  We complain about missing functionality here, broken functionality there, and it seems like we are never happy with the tools we have.  Call it perfectionism, call is realism, I am as guilty of it as the next person.

But this week I was reminded of the usefulness of Modifier, a tool that is often lumped in with Report Writer as having limited usefulness and causing frustration.  I think, as is often the case, the devil is in the details.  Proper scoping initially can ensure the proper development tool is selected for the project.  And for this project, the use of Modifier decreased the cost and maintainance of a previous Dexterity based customization.

When I was initially given the Dexterity customization to review, I noticed how basic it was.  Literally 6 modified windows, all based on existing GP windows.  No reports.  No procedures.  Nothing else.  And no source code, meaning that whatever road we took it would most likely involve recreating the customization.  In looking at the modified windows, the modifications we all cosmetic.  Changing the displayed size of fields (not the field itself) and rearranging headers.  I am sure the developer bloggers out there can add to my impression, but it seems to me that someone knew Dexterity so that is what they reached for as a tool.  Not the worst reason to pick a customization tool, but definitely not the only factor to consider. 

So, based on the fact that the modifications were cosmetic, Modifier was my tool of choice.  Easy to use, I modified the 6 windows quickly and easily.  No concerns about source code, additional dictionaries to install, etc.  No Dexterity (not that Dex is bad, but it does mean involving a developer each time)  And when it comes to upgrades, the process is fairly simple.  And, if the window changes and upgrading is not possible, it is easy enough to recreate now that we have documentation of the customization.

I recognize that Modifier may not be the best choice when getting in to heavy customization, but for cosmetic adjustments it works just great.  And with Business Ready Licensing, clients don't even have to own Modifier to run the modifications you create.  They just need the Customization Site License which is part of BRL. 

So the lesson here, I think, is pick the right tool for the job and save the client money while saving time now and in the future.  I know I have cited this white paper before, but Choosing A Development Tool is a worthwhile read for both consultants and customers who want to take ownership of their development projects.