New From Microsoft (NOT Software!)

There's something new from Microsoft, and it's not software. It's a methodology called Sure Step.

Why am I excited about a methodology? Because Microsoft has recognized that the reasons that projects fail or customers are unhappy with their system rarely have to do with the software. Just Google "why projects fail" (e.g. here, here and here). You typically don't see "the software was missing important features" as the reason. Project management issues usually top the list: lack of planning, scope creep, poor communications, lack of a proven methodology etc. etc.

In the world of medium sized accounting packages that I work in, project management is often viewed by customers as an unnecessary frill. When creating project budgets, I stopped putting in time for project management because it was routinely removed in the price negotiations with the customer. Instead, I built in time to create a project plan as well as for status meetings and progress reports.

The consultants and the software companies only have themselves to blame. During the sales process we minimize the difficulty of implementing new software. We talk about how easy it is, how everything is menu driven and can be accessed with the proverbial one click of the mouse. We minimize the work that needs to be done by the customer: designing their chart of accounts, downloading history from their existing accounting system or putting thought into how they want the reports to look.

Unless customers see themselves as at least a 50% partner in the success of the project, I guarantee you they will not get full use of the system they invested in. I'm not talking about a dramatic failure here. The result will just be that staff will not abandon their tried and true spreadsheets or side systems and embrace the new technology. Microsoft measures everything (just ask any Microsoft employee what getting a yellow or red light means). They measured software success and came up with the mind blowing statistic that 46% of software licenses go unused. This means that only half of the people you thought would use the new system will actually do so.

So, what should customers do? If you do nothing else, insist on a weekly progress meeting throughout the project, so you can be sure that the whole project gets completed, not just the minimum necessary to go live. The meetings should be short and only the senior people on the project need attend. This meeting is not for solving problems, it just brings them to light. The agenda is:

• What was accomplished last week
• What is planned for next week
• Where we are in the project plan (you DO have a project plan, right?)
• New or changed risks faced by the team

Weekly meetings force people to actually DO something or face the embarrassment of having nothing to report. They let you know who is waiting for whom. They inform everyone of the issues faced by others. They allow you to be proactive instead of just reacting to issues.

Also, during the sales process talk to your consultant about how they implement projects. If it's Microsoft software and the words "Sure Step" do not come up in the presentation, ask why. Ask them about what you need to do to ensure the project's success. Ask them how much of your staff's time you should budget for the project. If the answer seems too good to be true, then it probably is.

Accounting Software Consultants - Get Agile!

Agile Software Development has been around since the mid 90's and is gaining acceptance. If you implement mid-range packaged accounting software, like Microsoft Dynamics, you really need to look at this methodology. It is characterized by:

• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

The reality is that however detailed they may be, specifications documents never deal with all of the actual requirements. For example, it is a very rare spec that includes how to handle data entry errors, yet these are an important part of every system. What you really need is a process that puts the customer, the implementer and the developer at the same table, each constantly helping the others understand the requirements on the one hand and the system capabilities / limitations on the other.

I would argue that this approach should extend to training as well. Classroom training set up in a generic, simple company with prepackaged exercises that always work has a limited usefulness in my experience. It is more useful for clients to deal with their own system and learn to solve their own problems. For example, one of my clients does an international consolidation of numerous subsidiaries. Instead of designing a training course around the consolidation, I chose one subsidiary and converted it in a test environment. Then I sat with the two analysts and we did one together. As we finished each step, one of the analysts took a screen capture and annotated it in Word for our documentation. Finally, the analysts each did their own companies, with me available for questions. As we hit setup, data and security issues, we solved them together. The analysts came away with a better understanding of the configuration of their system than they would have had it been a pre-packaged demo that ran perfectly.

What do you think?