There are two perspectives to consider when hiring an enterprise architecture consultant. One is the perspective of the client, who might find that they invested money in a consultant who lacks the expertise they need. Unfortunately, there is no industry standard for what qualifies one to be a consultant; therefore, anyone can call themselves one.
Figure 1. How you view your consultant 1
The other perspective to consider is that of the consultant. If a customer is unprepared or has unreasonable expectations, a project can quickly deteriorate or ultimately fail. This experience aligns with an adage from a climbing guide: "Your client is always trying to kill you."
Figure 2. How your consultant views you
Hiring a consultant can bring tremendous value to your enterprise architecture practice, especially if you are new to these concepts. This paper provides some guidelines on how to select and get the most value from your consultant.
Do you need a consultant?
Before hiring a consultant, the first thing you should do is figure out if you really need one. There are a number of things consultants can provide assistance with.
Figure 3: Make your consultant a partner, not an adversary
Understand the problem space
Good consultants listen to client issues before suggesting solutions. Because most consultants have gained experience with similar issues at other companies, the consultant can suggest the appropriate action.
While working with a government customer in the DoD I realized the problem they had with logistics was similar to a problem I had worked on with a similar customer. I was not only able to suggest a solution that I knew would work, I was also able to put my customer in contact with the other agency for mentoring. The project was a success and was implemented quicker because the customer was able to use lessons learned and best practices from the other agency.
Separate technical issues from political ones
Sometimes customers face issues that are political, not technical. As an unbiased observer, a good consultant can point out the differences to a customer.
As an example, I worked with a client who thought his company needed a new system for managing projects because the current system was not working. It turned out it was not working because the process was broken. The client was able to fix the process and then the existing software started providing value. Because I was able to recognize this breakdown in process, the customer ended up saving thousands of dollars.
Assist with architecture analysis
Often, customers create architecture, but need assistance with their next steps. Good consultants can teach customers how to use their existing data to provide analysis and value so the architecture proves sustainable.
Consultants should also have experience working with enterprise architecture in multiple environments. A consultant who has only worked in one industry might not have the breadth of knowledge to provide the best solution to a customer. Normally those types of consultants only suggest the approach that they are familiar with. While that is not necessarily a bad thing, some customers require a little more creativity when approaching their architecture.
Understand tools and how to apply them
Good consultants have experience working with multiple tools. Consultants who use only one tool might end up forcing the customer to use software in a way that the original design did not intend (For example, using an architecture tool to manage requirements – I have seen companies do that). There is not a single software tool in the market that does everything required to have a good enterprise architecture. Even if there is, it would be too complex to use. Having a consultant that knows enough about enterprise architecture tools to make recommendations is invaluable.
Consultants can also help translate the promises made by sales into a reality. It is the nature of sales to tell a client that a tool can do everything the customer wants. The consultant is then left to try to turn the sales promises into reality. Consultants can tell the client when a modified tooling approach would serve them better, or recommend other tools as new requirements come up on a project (e.g. the ability to publish the enterprise architecture).
Figure 4: Your consultant should teach you new tricks
I once had a client that, as their enterprise architecture matured, wanted to do more powerful planning analysis than was available in their tool. Sales recommended that they get me to customize the tool to provide the analysis. But because I had experience working with a software tool that would meet the customer requirements I recommended off the shelf software instead of hiring me to do the customizations. It might seem strange to tell a customer not to spend money hiring me, but in the long term the solution suggested to the customer by sales would not have succeeded. The client still works with me because I gained their trust.
How do you find a good consultant?
As mentioned before, anyone can say they are an enterprise architecture consultant, and there are a number of programs that award someone with a certificate to make it official. This does not mean the consultant knows what he or she is doing or has actual experience.
The following guidelines can help you find a good consultant.
Real world experience is key
Do not hire a consultant if your project is their first project unless they have an experienced consultant working with them. Even if the first-time consultant is knowledgeable about enterprise architecture, it can be difficult to assess the best approach to take on a project, and things always go wrong. An experienced consultant is often prepared to make sure that when things go wrong they are fixed based on best practices and experience, rather than ending up with a work around that breaks as soon as the consultant leaves.
Flexibility in problem solving
A good consultant is flexible in their approach to your project rather than forcing you into a proscribed process that may not provide you with value.
I have seen consultants who, for example, tell a client that they have to collect a specific set of information regardless of whether or not the client is going to use the information. At one customer site the consultant spent 6 months collecting information on business processes, because that was his company's methodology, even though the client's immediate need was to consolidate their application portfolio.
Experience developing models
Somehow people who have never drawn a single diagram consider themselves enterprise architects. That is like calling yourself a climber because you live near some rocks.
Modeling is as much an art as it is a science. Like climbing, the more experience your consultant has with developing models, the more value you can get from their analysis of your current architecture and the models that they might create for you.
Your consultant should have at least a year of solid experience with the methodologies that you use, such as BPMN or UML.
Experience with industry standards, not home grown solutions
On an engagement with a very large oil company I was horrified to discover that the 5,000 business processes they had captured for their enterprise architecture were created using a "methodology" invented by their consultant.
Conveniently for the consultant, no one else could really understand how the methodology worked. But looking at the different processes, there were massive inconsistencies on how things had been modeled. Most of the processes were useless for doing any kind of analysis, and the client could not use them because they were not in an understandable format.
Insist that your consultant uses industry standard methodologies to develop your architecture. They should be expected to be familiar with many of the industry standard methodologies in their area of expertise. For example, a consultant who is an expert in business processes should know what BPMN is.
Knowledge of case tools
Your consultant should be familiar with at least one case tool that supports the development of enterprise architecture, but knowledge of more than one tool is better. Given the scope of your project the proper tool can save time and money in the development and management of the architecture.
Your consultant should not suggest using a tool without a repository (e.g. Power Point or Visio). Most of the value derived from enterprise architecture has to do with the ability to report on the data and its relationships. A tool that does not support reporting can drastically limit the ROI of your enterprise architecture.
Further, you will end up spending most of your time and money updating models rather than analyzing models. As an example, if you have 100 business processes captured in Visio, and the name of one of your departments used in the processes changes, the only way to make that change is to open every diagram and update the information manually.
I have run into a number of consultants who swear they can do do modeling in PowerPoint and spreadsheets. Do you really want to pay someone a lot of money to do manual labor instead of doing real enterprise architecture work?
How do you manage your consultant?
After you hire your consultant the hard part is not over. Your consultant has to deliver. There are a number of ways you can nurture the relationship with your consultant to get the most value from the experience.
Figure 5: Does your consultant look confused?
Statement of work
Have a statement of work and ensure that the deliverables in it are well defined and valuable. For example, a deliverable of "document the first and second line processes for aircraft maintenance" is better than "document maintenance processes" because the consultant will understand what information is important. It is common for a customer to be unsure about what their deliverables should be. A good consultant can help you define what they are before the engagement starts.
Tailor a prescribed approach
Many companies have a standard process and set of deliverables for consulting engagements. Standardization is good because it is a tested and successful approach. However, not every customer needs the same deliverables or results from an engagement. Your consultant should be able to tailor a prescribed approach to meet your needs. For example, if the typical engagement involves producing a website with the results, and you don't want a web site, that deliverable should be replaced with something else of value.
Have waypoints during the engagement to check your consultant's progress. You don't want to find out the day the consultant is leaving that deliverables weren't met. Weekly meetings are useful for long engagements. For shorter engagements (three weeks or less) meeting at least four times before the final day of the engagement will point out any issues or areas where the consultant needs support.
Things you should consider at the waypoint meetings include whether the consultant is meeting expectations and whether work is getting done on time.
Subject matter experts
Even if your consultant is an expert in your line of work, every company is different. I am always amazed when a client hands me a huge spreadsheet and expects me to know what the data in the spreadsheet is, what information in the spreadsheet is important to the project, and who to contact if I have questions.
Figure 6: Keep perspective - project problems are not life threatening
Having your consultant work with, or have access to, a subject matter expert will help prevent rework when you discover the consultant made the wrong assumption. It will also help the consultant have a more complete understanding of what information is of value, especially if there is a lot of data and a limited time for the engagement.
Sometimes, things go wrong
Even the best projects and the best consultants can run into issues. The following tips can help you get the project back on track.
Rescope the work
Customer expectations can sometimes exceed the time allotted for the consultant. Also, lack of preparation can also cause issues. By rescoping the project you can ensure that you get the critical deliverables and that "nice to have" deliverables are secondary.
Develop and agree to a rework plan with your consultant to make sure everyone understands the changes and modified deliverables.
Determine if the problem is the tool, the project, or the consultant
Customers occasionally try to get a tool to do something it was not meant to do. That can cause extra work for the consultant that was not accounted for in the statement of work. Projects can also have issues, such as lack of support from the project members or political issues that make it hard for the consultant to get information.
Internal politics can derail the most competent consultant. For example, make sure to keep your consultant in the loop if there is a change within your organization. I have worked on three projects where the person I was working for was unexpectedly fired. It made for an awkward Monday morning to walk in to the client site only to discover my customer's desk was empty. You may not always be able to share information with your consultant, but at least give an indication that, for example, they will be working with someone new when they return from the weekend break.
There are bad consultants. But before you automatically blame the consultant look at everything in an unbiased way and see if there is a simple fix (e.g. getting management to support having their people participate in the project) before blaming your consultant.
Figure 7: Ignoring your consultant can have unexpected consequences
Also, changing the objectives of the project might change the skills that you need from the consultant. If you suddenly decide you want to do simulation instead of a website, you might need a different consultant if your consultant has no experience with simulation.
Engage more with the consultant
I personally have worked on projects where my customer put me at a remote desk and did not respond to my emails or phone calls until the end of the project. Those projects, obviously, were not as successful as those where the customer was fully engaged. If you do not have time to work with your consultant try to find someone else that the consultant can meet with.
Figure 8: Find issues before they become issues
Your consultant is not always a menace
The biggest value your consultant provides is experience. Don't assume the worst if your consultant tries to change your approach. The advice is likely being given to help you succeed or to protect you from failure. You consultant is aware of long-term consequences in following an approach that may not be readily apparent to you.
I once had a customer who wanted to manage application data in a software tool that was not a CMDB tool. Initially the customer refused to listen when I tried to explain the problems involved with doing that. After I provided an analysis that showed how many people hours would be required for their approach they took my advice and purchased the right tool.
Before your consultant leaves
At the end of the engagement, you hopefully have a successful project. Make sure your assumption is correct. A few days before your consultant leaves you should take the following actions:
- Test the consultant's approach and make sure you can follow it without the assistance of the consultant. Once you stop paying the consultant, he or she is unlikely to answer your panicked phone calls.
- Understand the administrative overhead. Make sure the approach is not largely manual and that it does not require more people or a different skill set than you have on your team to carry it out.
- Develop future steps for your enterprise architecture program so that you have a plan to evolve it over time. If you aren't providing new value it might be hard to get management to pay for your program.
- Make sure the current implementation supports your plans and will not require a lot of rework to move to the future state. A good consultant should provide you with a flexible solution that can be scaled up.
- Look at options for further consulting, if needed. This will help your consultant plan his or her schedule. It's normally helpful to bring back a person who knows your enterprise architecture rather than bringing in someone new who will need time to understand your approach.
- Make sure all deliverables have been met before you consultant leaves. It is much harder to get deliverables after the project is over.
After your consultant leaves
Blame your consultant. That's what you paid for.
Figure 9. Best of luck with your EA!
Special thanks to Joe Josephson, First Ascent Press www.firstascentpress.com for providing pictures.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.