I have a simple method for getting incremental revenue out of ERP users, touch them. No, not in a creepy, restraining order kind of way. Go visit with them. Yep, that’s all it takes. There is something about face to face interaction that makes people ask questions, explain problems and look for solutions. It is almost universal that when I walk into a client, they need more than I’m able to give them in a single visit. It comes out in the form of “We’re having a problem with…” or “Do you know of a solution to…”
This is one of the reasons why partners do so much business at events like Convergence. Users that would never pick the phone and ask for help will show up with a laundry list of requests. Of course, you don’t have to wait for an event, you can throw your own event around something like the GP 2013 launch. You can also just go and visit them with nothing to sell. Show off the free Professional Service Tools or the free Support Debugging Tool. Give a little value before you get. That’s the definition of real partnership.
This works really well if you have folks on the bench too. Call up clients and give them a free consulting hour on anything, Smartlists, Excel Reports, you name it. If the ROI isn’t at least 8 hours of billable time, the consultant is doing something wrong.
As the old AT&T slogan went, “reach out and touch someone.”
Dwight is of course free to disagree with me on this post. It’s his site after all, but then again, he gave me the keys…
I read a lot of things outside of my specialty because I learn things from people smarter than me and let’s face it, there are lots of those around. This time it was Search Engine Journal of all places. Yes, Search Engine Journal is nerdy even for accountants.
They’ve got an incredibly coherent article on When to Fire Your Client. There are times when you’ll take cash flow, even if it’s from folks who ultimately cost you money. 2008-2010 was like that for a lot of firms. Then there are times where you need to recommend some clients to your toughest competitor so that you can get unstuck and grow the business. Let the competition crow about the win, even as the life is slowly being sucked out of their organization.
Their five key indicators that it’s time to fire your client are:
- They Stop Respecting You
- They Don’t Value Your Time
- Questioning Your Time
- You are working for pennies
- Where did the ROI go?
If you hit three out of five they recommend that it’s time to take a hard look. Item 1 is the roughest from my point of view. There’s nothing like wondering why folks asked you to come down if they are going to hold up a counterpoint to every one of your recommendations.
Read the full article for the details behind the recommendations at Search Engine Journal.
The Dynamics world is changing. New partner requirements, Master VAR’s, the cloud, mobile, you name it. Somedays there’s so much angst among partners that I feel like I’m at a Twighlight convention full of teenage girls.
Well, we’re not the only ones going through an upheaval so I thought some perspective from a different industry might be in order. The book business is dominated by a few large publishers and distributors with lots of small and independent publishers. Toss agents and authors in the mix and its lots of fun. Amazon and digital publishing are disrupting this significantly, essentially blowing up a very old oligopoly.
We’re seeing some parallels with cloud computing disrupting the traditional ERP space so here are some thoughts from the book world.
J.A. Konrath is a traditionally published author who has moved very successfully into the indie space. He’s not shy and his post Amazon will destroy you seems most relevant.
Agent Rachelle Gardener has 3 new posts on the changes going on including:
Certainly all of those questions are relevant to us.
Finally, if you have trouble applying lessons from other businesses to yours, I have to wonder how you manage to help other businesses through the change of a new ERP system.
Marketing guru Seth Godin hits the nail on the head with his look at Talent and Vendors. Please go read it. As resellers we are technically vendors but the “Value Added” part is what makes the difference. The application of talent to deliver the right solution is what sets one reseller apart from another.
From the article: “That’s the key economic argument for the distinction: if you treat an artist like a vendor, you’ll often get mediocre results in return. On the other hand, if you treat a vendor like an artist, you’ll waste time and money.”
And: “A key element of the distinction is that in addition to the varying output potential, vendors are easier to replace than talent is.”
Personally, I hate when I’m trying to apply “Talent” ie. a novel solution, a cheaper solution, etc. and get treated like a “Vendor”. Some of my favorites are “We’ll just white that out when they print on the P.O.’s” or “We’ll just track that in Excel.”
Understanding which clients want talent and which ones just want a vendor is an important part of the relationship. Of course, then there there are companies that want to get talent but only pay for a vendor.
Maurilio Amorim has an interesting new post on Red Flags Your Business Relationship is in Trouble. The lessons in the post apply well to Dynamics partners. The first two items, Communication Blackout and Justification Inquisition should be common sense to anyone who has spent any time with another human being. If the client is not communicating or requesting considerably more information and documentation than normal, you have a problem.
The next two items, dealing with the Internal Teamer and More for Less, are both very applicable to Dynamics partners. We’ve all seen cases where a client hires someone internally hoping to reduce consulting fees. Maurilio’s advice is “Play Nice”. Often the client doesn’t get the savings or efficiency they were looking for. I would add, make the internal hire your friend. Frequently the expectations placed on the internal hire are unrealistic. They are being tasked with replacing a team of consultants and find themselves desperately looking for help. You have the opportunity to turn the Internal Teamer into and advocate for your firm.
More for Less is the critical lesson we all need to internalize. Lowering fees and increasing output devalues your work, especially when you do that to save a client. Read Maurillo’s whole post for the details.
I think that the Dynamics community as a whole has a lot of room for improvement in conducting any kind of formal post project review and I think that there are a number of reasons why. Specifically:
- Despite the Sure Step process of “releasing the implementation team” the reality is that often much of an implementation team trickles off incrementally as part of post implementation support. Rarely (never?) is there a close the project meeting where everyone goes off to new projects.
- Team members may be move on and off projects for specific tasks that go live at different times.
- Its expensive in terms of unbilled hours and possible travel to pull together a team for a post project debrief.
I still maintain that an effective post project debrief would got a long way to improving future implementations, spreading institutional knowledge and building better teams but those are soft items and they bump up against the lost billable hours required for a review.
I don’t have any great answers for this problem. I’m hoping that the addition of the Sure Step Project Review Document will help facilitate this process both at the end of a project and at major milestones. I also think that the project review needs to be done with only partner personnel, not shared with the client. A separate review with the client may be appropriate but In many cases the discussion can center around how to better deal with certain types of clients. That candor is critical and won’t happen in a mixed environment.
So here is my call for improvement.
- Do you conduct consistent formal project reviews?
- How we turn off the cuff reviews like “that project went well” or “that project was a mess” into something actionable on future projects?
- What suggestions do you have to encourage more post project reviews?
Post your comments here or email me at firstname.lastname@example.org
I looked last month at How Not to Annoy Your Consultants. This month I wanted to tackle one other issue mentioned in Scott Berkun’s book Making Things Happen, namely processes.
Scott defines a process as “any repeatable set of actions a team decides to perform on a regular basis to make sure that something is done in a certain way.”
Since poor processes are often a source of annoyance, this is something of an extension of last month’s post but it’s more than that. Processes are required in any business. Even the one man artist has a consistent approach to a project that is really a process. But processes are a lot like meat, they are fantastic when done right but they decay quickly. Simple processes that are given a lot of work up front have the longest shelf life. To go ahead and butcher this metaphor, think beef jerky. (The puns are free.)
By their very nature processes decay by:
• Increasing in complexity
• Not changing with the business
• Not changing with technology
Decaying processes are worse than decaying meat. Both can make you sick but meat at least warns you with that funny smell and odd color.
Every process needs a review at least annually. Every process…period.
Scott goes on to present a simple formula for evaluating the Return on Investment for a new process along with guidelines for creating better processes . Business owners and executives should pick up Making Things Happen and zip through chapter 10. Go do that now. This means you Dwight. Don’t worry, you can expense it per Mark.Go on.
Ok. Now that the executives have gone we can talk about real process issues. Sometimes there are processes that you can’t change. For managers in the middle this requires a lot of finesse. An example would be a practice manager, department head or even project manager trying to deal with processes that conflict with their employees ability to get work done.
What kind of processes keep people from getting work done? Maybe it’s a stupid process that doesn’t permit the scheduling of sick time. So surgery doesn’t count as sick time or do you not want be warned when employees will be out for surgery? Stupid. It could be a legitimate process poorly implemented. Expense reporting is a legitimate process but with a few crappy forms and complex approval processes it’s possible to increase the difficulty to near homicidal levels.
Well meaning executives can still create stupid processes and sometimes it takes a while to get them to change their mind. What should managers do with poor processes in the mean time? Well Scott tackles that as well and the three options are:
• Shield your team from the process
• Bet against the process
• Ignore the process
Shielding the team from the process may mean taking on extra paperwork or creatively interpreting the rules. The best consulting managers I’ve ever had are experts at this. The problem is that stupid processes, even if poorly enforced, are a drag on morale. The success of betting against the process depends on the organization.
In other companies I’ve bet my Dynamics GP career against Siebel, Solomon and Navision initiatives over the years and come out better every time. Open revolt is not recommended, feet dragging and passive/aggressive behavior works better. It also helps a lot if you are really good at what you do.
Finally, just ignoring the process can sometimes work. Ignoring the process also works well for processes that are not highly visible, grossly unrealistic or physically impossible. For example, if a process requires time to be submitted by Friday at 5pm but in the history of the company no one has ever processed that time before Monday morning, feel free to push the limits.
There is one other thing I would add for stupid processes. Consider the consequences. If the CEO declares that not following the process will result in termination. Follow the process. Wait it out and keep trying to change the CEO’s mind. If the penalty is a slap on the wrist, maybe, sort of, if you get caught. Don’t get wound up about it.
Now you’re asking, does I.B.I.S. have stupid processes? Yep, we’ve got a couple. In fairness it’s fewer than some companies I’ve worked for and only a few of them are Dwight’s fault. Every so often one of us gets worked up about it and sometimes the issue gets fixed. Sometimes it doesn’t. Draw your own conclusions about how the consultants deal with that.
I just finished Scott Berkun’s project management book titled Making Things Happen. The book is highly recommended for PM’s and managers alike. One of the more unusual areas was chapter 10, How not to Annoy People. At the beginning Berkun covers the kinds of things that annoy people and I found that every item on the list applies to consultants.
It is impossible to run a successful Dynamics GP practice of any size without consultants. Good Dynamics GP consultants are always in demand, even more so as the economy starts to improve. They are also expensive. So why do companies still do things to annoy their consultants? I’m going to assume it’s just ignorance and we’ll see if we can get better together.
How do partners annoy consultants?
Assume a consultant is an idiot
Consultants were hired to implement Dynamics GP. When consultants are treated as if they can’t do that, it annoys them. A 20 step procedure, daily evaluation, rulebook or any other process that implies that a consultant is not competent is annoying. Certainly the company needs standards but until the consultant proves their incompetence they should be treated as if they can do what they were hired to do.
Don’t trust a consultant
When consultants are expected to check in, double check, triple check and report on decisions that are well within their range of responsibilities, it’s annoying. When consultants have to confirm everything with someone else, they aren’t really consultants, they are robots. If a consultant has demonstrated a reason not to be trusted then management should provide a defined path back to trust or cut them loose.
Waste a consultant’s time
A consultant’s time is precious, they know exactly what it’s worth. It appears on a bill every week. Most consultants I know only have two types of time, billable and family. Anything that wastes either of those is really annoying. When consultants have to over document because management is over protective, it’s annoying. When there are flip flops on important decisions its annoying. When poor management decisions lead to rework and wasted time, it’s annoying. When consultants have their time wasted in unnecessary meetings, it’s annoying.
Manage Consultants without respect
When a project is grossly underestimated and the burden put on the consultant to fix it, it’s annoying. When consultants are given assignments that have no basis in reality it’s disrespectful…and annoying. When a consultant is asked to pick up a book and learn enough Sharepoint to teach an advanced class on it tomorrow, it’s really annoying. A consultant should be supported by management not abandoned by them. Stupid processes fall in here somewhere too but that is a whole other post.
Make consultants listen to or read stupid things
For Dynamics GP consultants this includes asking them to learn stupid things. In my career I’ve been to classes for Siebel, Solomon, CRM and Sharepoint. None of them have advanced my career as a GP consultant. Consultants are asked to read, attend webinars, sit in on meetings, listen in on conference calls. Easily half are annoying. Work hard to identify the half and cut them out. Cut out too much. Good consultants will ask to get back in.
Before anyone tries to read too much into this, I have worked for a number of different partners organizations. I don’t find I.B.I.S. to be very annoying. This not true of some other partners I have worked for. Andy and the folks at I.B.I.S. always treated me with respect and been willing address annoyances when I bring them up. Can your firm say the same thing about your consultants?
<Start shameless plug>I couldn’t figure out how to work it into the body so visit DynamicAccounting.net for more Dynamics GP information and preorder my book, the Microsoft Dynamics GP 2010 Cookbook as a present for your clients. <End shameless plug>
This article is much more partner focused than my normal blog posts at DynamicAccounting.net so Dwight has graciously given me the opportunity to guest post here.
If there is one thing that project managers and consultants dread, it’s getting client signoffs. I don’t mean signoffs on sales documents. I mean signoffs on the completion milestones as the project progresses. Let’s face it, signoffs are a form of confrontation and most people hate confrontation. This leads to reluctance to ask for signoffs. Couple that with clients who withhold signoff in a bid hold partners hostage and end users scared to take responsibility for anything and it’s easy to end up in signoff hell.
Every partner has been through signoff hell and I think that we have found some ways to at least mitigate the problem for everyone. I make no claim to having created these processes, I’ve simply seen how well they work and tried to document and refine them. My experience is using these techniques with Dynamics GP implementations but there is no reason why they won’t work with other products. The process steps are:
1) Figure out if there is a problem. – Use signature tripwires early in a project.
With a new client, how does a partner figure out if this client will have a problem with signoffs? The answer is to use tripwires. Early on, in the first phase of a project, build in several artificial signature points. Make them meaningless items that anyone would sign off on. Use something like reaffirming already confirmed dates, signoff that the kickoff meeting happened, etc. Whenever possible push these signatures lower in the client organization. This also builds confidence when asking for signoffs because a signoff is expected.
- If multiple levels of people at the client organization sign off without a problem, you may be able to safely move to signoffs at major milestones.
- If people balk at signing these innocuous documents, it’s time to increase the amount of signatures required on this project.
2) Houston we have a signature problem. – Increase the volume and frequency of signatures.
The solution to the problem of obtaining client signatures is to get more of them, more often. I know that this sounds counter intuitive but it’s not. The core problem is that users see signoffs as scary events with potentially negative consequences. The key is to turn signoffs into a routine.
- Communicate that for complete project documentation, there are going to be a lot of little items to be signed off on. Failure to provide timely signatures will impact the timeline and the cost. Communicate this often, especially in front of senior management.
- Get every little thing signed. After a while, management gets tired of the roadblocks and they get tired of hearing about it in the status meeting. In this way, the client figures out how to make signatures happen.
- Workout with management who can provide alternative signatures to deal with signature bottlenecks from vacation or business travel.
- Steer documents that could be signed by several people to the one(s) most likely to sign.
- Don’t skip the big milestone signatures either. These are much easier to get signed with a pile of signed sub-steps behind the document. This signature also provides some protection should a partner miss getting a sub-step signed.
Partners will have to push a little. Some people refuse to take responsibility no matter what but they start to look pretty silly pushing minor signatures up to their manager over and over. Usually, a manager at the client fixes this for a specific problem user.
3) What if they still won’t sign? – Ask what the items and concerns preventing signature are.
When the client still won’t sign a particular document, it’s time to dig deeper. Clients often have very good reasons not to sign documents. The concern may be open items, completeness or understanding of a process. The key is to understand what it will take the client to sign.
- Ask the client, what items or concerns are keeping them from signing the document. This forces a clarification of the issue. The key is to get direct answers not vague generalities.
- Address those items if possible right then and there and get a signature.
- If addressing the open items immediately is not possible, split the document to be signed into two documents, one for signature and one for the open items. This keeps progress moving while providing peace of mind that a critical item won’t be missed. It also forces documentation of the specific issues or missing elements. This provides a commitment to sign once these items are addressed.
- Alternatively, ask them to sign and note any exceptions. This doesn’t provide the same level of comfort as two documents but it does force documentation of the specific issues to be addressed.
Part of this process is to get problem items to move to the surface quickly. Some of these items may need to be escalated to the client or the partner’s management. It’s easier to resolve difficult items when they are found earlier and frequent signatures requirements force these items to the top.
4) What not to do. – Don’t manipulate.
All of this advice assumes a competent, professional partner working hard to implement ERP software. This is not a license to bully or manipulate clients
- Bullying users to sign a document is unethical, don’t do it. The point of this document is to help build a culture at the client that is comfortable overcoming fear and moving forward with the process. Bulldozing through the process and bullying people to sign will not provide the desired result.
- Don’t manipulate clients by sliding in a difficult document with a pile of easy to sign documents. An ERP implementation should be an open process. Slipping documents past customers won’t work for long.
- Don’t end run an approver. If there is a primary approver for a document and they are available, don’t use an alternate approve just because they are more likely to sign. Also, don’t go over an approver’s head to get a signature. Ultimately, you may need to go to a manager to overcome a user who is blocking the approval process, but that is different conversation. You are not trying to raise the approval up a level; you are trying to keep the process moving forward.
The best part of this approach is that it works just fine with Microsoft’s Sure Step project management approach. Getting a signature on each Sure Step document is a great place to start. You may need even more granular signatures depending on the project and the client. There is relief from signoff hell and it’s not as hard as people think.