The Passionate Consultant

Tucked away in the middle of the Latin Quarter of New Orleans is a hole in the wall dedicated to music. Not just any music, but jazz as it was played way back when. "Nawlins" is full of songs and this band knows them all. The Preservation Hall Jazz Band loves what it does. The plaster is barely hanging onto the walls. There is no sound system. Most of the people squeezed into the small space have to stand, but nobody cares. It's all about the music. Listening to it, I was struck by how happy it sounded, even when they were playing the blues.

After the show was over, we moved to a bar down the street. Also dedicated to jazz, this bar had polished tables, a stage for the band and a full sound system. But somehow the band just didn't seem to have that same passion for the music. They were all great musicians. The quality was good, but it looked to me like they were just doing their job.

Consulting is like that. At the end of the day, you don't hire a firm, you hire a person or a team. If they have passion for what they do, then they will put in the extra effort to find the best fit between you and your accounting system.

So how can you tell the difference?

Most firms will claim to be passionate about what they do. Usually, it's true. One or more people working there will truly have that extra drive. The question is, will they be on your project?

Here are some tips:

1. Before you agree to hire the consultants, meet the people who will be on your team. If the team is changed, you need the right to approve the new people.
2. Ask about experience with your industry / size of firm / geographic location. Make sure it's not just the consulting firm who has that experience, but it's also the team members.
3. Follow up on customer references. Ask the other customer about how well the team worked as well as the accounting system. Ask them what they would do differently the next time.
4. Passion is an emotion. Ask the proposed consulting team to describe other jobs they have worked on. Look for clues in their words, voice and body language. Are they enthusiastic? Do they embrace challenges? Is their language clear and direct? Can they talk intelligently about other, similar projects?

One thing: you have a major responsibility too. If you are not passionate about what you do, how can you expect an external consultant to be passionate? If you delay the project, how can you expect the consulting firm to hold the consultants until you are ready? If you are not clear about what you need, how can you expect a successful result?

If We Could Do It Over

Two manufacturing customers were comparing notes as I sat down at the lunch table at Convergence, the Microsoft customer convention. Customer A was considering Microsoft software and Customer B was close to "going live" (i.e. stopping their old system and using the new one exclusively). In the course of the conversation, Customer B made four major points:

1. If we had to do it over, we would have more training of our development staff at the start of the project.
2. The project was a lot more complex than the VAR (the consulting firm that sold them the software) realized.
3. The VAR refused to admit that they had done anything wrong. They just kept charging time and materials regardless of how many resources they threw at the project.
4. We stopped letting the VAR run the project.

These are good lessons to consider if you're about to launch into a project, particularly when it involves processes that are as complex and company specific as manufacturing.

More Training

Training is tricky. If you do it all at once, there is a tendency to forget the material or get overloaded. If you do it too late, the customer may already be frustrated by working with a system they don't understand. It's a good idea to leave space between sessions to allow the people time to absorb and hopefully apply the lessons, but training needs should be raised at the regular status meetings to be sure nobody is spinning their wheels. You do have regular status meetings, don't you?

Complex Projects

The concept is simple. You design a product, build it and sell it, right? The deeper you get into a project though, the more complex it becomes. Sometimes, even the customer's managers don't appreciate the complexities. It isn't until someone who actually processes the transactions sees the system that some issues emerge. If the discussion gets to finger pointing, you've lost. People will stop talking and start blaming. This problem has to be stopped before it starts. From the beginning, both sides have to take the position that this is a joint discovery process. The key is constantly checking the assumptions and progress. That's another good use of regular status meetings.

Billing and Milestones

Customer B brought up a nice idea: set up the project as being time and materials, but once the milestones are set, get a firm quote for each one. That spreads the risk between both the customer and the consulting firm. I don't have any experience with that scenario. If you do, please leave a comment.

Whose Project Is It?

Project Management theory is clear on this point. The project is always the customer's responsibility. The customer leads the project. It cannot be effectively delegated to an outside vendor or subcontractor. If you don't have a qualified person on staff, engage an independent project manager. The consulting firm can and should have someone to manage THEIR responsibilities, but that person should not be put in charge of the whole project. They have neither the authority to delegate work to the customer's staff, nor do they understand the full scope of the project.

Resolution

To resolve their issues, Customer B took control of the project and went directly to Microsoft and the developers of the add-on package that handled manufacturing. The project ended up exceeding budget, but they are close to going live and are confident that the software will work for them. Their experience will help them in future projects, particularly if they document it as part of a Lessons Learned session.

Systematize / Projectize - Which?

Month end again. The normal processes kick into gear as we ensure there is a good sales cut off, the expense reports have been submitted, the banks reconciled and the overseas operations results are ready for consolidation. On the whole, month end is a well oiled machine where everyone knows what is expected of them. That's the mark of a good system, particularly if all of the processes have been documented and people check them off as they are completed.

Most of the work of the accounting department can be systematized, i.e. turned into a pattern of regularly recurring processes, but what about the surprises? You know, the President is looking at purchasing that little plant in Omaha, you need to have a Sarbanes Oxley review, the accounting software needs to be updated, the Chairman wants a five year forecast, etc. When the accounting staff have their hands full with the system, how do you handle these unpredictable requirements?

The answer is to projectize. Let's face it, even though nobody can predict what surprises lay in store for you next month or next year, you know for certain that they will be there. Why not include them in your planning?

Personal Goals

You know some of the projects that have to get done. In fact, some of them may have been waiting a long time for someone to have enough time to address them. At a recent client, I commented on how enthusiastically one of the staff had taken to the new reporting software. "That's because the new Controller included it in her personal goals for the year," the Assistant Controller said.

"Great," I replied. "What's your goal?"

"Clean up the GL," she said, with a sad smile. It was a big job.

Delegating projects to people is good, but that's only just the start.


Resources, Tools & Time

Of the three techniques available to a project manager, finding the time can be the hardest. Whatever else you do, the accounting system must be maintained. On the other hand, project work can be fun. It's a break from the routine. People get a chance to learn new skills and work independently. What better way to prepare someone for their next career step than to give them a project to manage?

In my experience, the best way to make room in the schedule for project work is to be open with the team about what you are doing. Then enlist their help in finding faster ways to do the normal work, such as automating or eliminating manual processes, getting transactions booked properly the first time rather than adjusting them at month end and reducing any duplications between separate systems. If the whole team is motivated to save time, the results will be much better than a solo effort by you. You might have to make it clear that your objective is only to save time, not to reduce headcount.

Resources and tools are other issues that you have to address. Your team members may need training to take on the projects, whether a formal course or coaching from someone more senior. An outside consultant may be necessary, but encourage your team to work independently. Have them create a project plan and come back to you with any additional resources they think they need. Finally, insist on regular updates and status reports. After all, as head of the department, you are still responsible for delivering the goods.

So, should you systematize or projectize the accounting department? The answer is: both.

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?

Project Management

The July edition of PM Network, the monthly magazine from the Project Management Institute, ran a feature on the importance of project management on small projects. When you are building an airport, putting a man on the moon or constructing a nuclear reactor the need for planning and organization are clear. What this article points out is that the consequences of not properly managing a three month project can be just as disastrous for the organization.

What is Project Management? It is the distillation of the scars and bruises from thousands of endeavors into a model of good planning and follow up. The principles are self-evident. The discipline of applying the principles consistently is priceless. Here's a quick summary:

• Schedule Management - putting everything on a calendar
  
• Team Management - marshaling your human resources
• Communications Management - keeping everyone informed
• Quality Management - assessing the output
• Risk Management - planning for what could go wrong
• Change Management - not letting the size of the project get out of control
  

A good summary of Project Management principals is on the Human Resources and Social Development Canada website.

In my field of accounting software implementation, there is a tendency to describe experienced implementers as project managers, whether they have project management training or not. I will be forever grateful to the former IBM consultant who took me aside on a project and said, “If you want to be a real project manager, take the courses from the Project Management Institute.”