As a consultant and the director and controller of a software consulting company, I’m often regularly engaged as a consultant on new projects with new clients as part of a contract for services business relationship. As a consultant it’s important to continually apply and refine your own methodology and rules of engagement to your client’s projects and be solely responsible for how you do the work to deliver on the agreed upon deliverables. This article is going to describe strategies I use, and that I employ others to use when engaging with new projects as a consultant as seen through the lens of my own experience as a software consultant primarily focused on architecture.
It’s of the upmost importance that you understand the business of the engagement and how the project impacts the overall capabilities of that business. For example, business development and supply chain are two different capabilities within a single organization that require different sets of experience or knowledge, but because much of software consulting concepts are transferrable between business verticals, there are a variety of ways to get up to speed on aspects of a client’s business. You should always understand the business your client is in, continually refine that knowledge, and rely on your own network and their experience. Personally, I’ve built up a modest size professional network, and I’m not above a phone call or in person coffee meeting to understand from other people about their experiences in specific business verticals. Solidifying your understanding of the business vertical, capability, and goals of the project early on will be paramount to the success of your deliverables. Solidify this early, and refine and increment as you go along.
Ask a lot of questions and take a lot of notes, and keep referring to your older notes while revising them as you go. This is critical as you build a personal knowledge base of information that will be critical to you as an architect and consultant. Personally, I tend to take a lot more notes at the beginning of a project to refine my understanding and to ensure that I’m always making the best use of my time and the client’s time. This helps me hone in on my gaps in knowledge and allows me to ensure I am always asking the most important questions as time goes on. This will also allow an understanding current and target states much earlier.
Although as an architect you will often be required to identify what the current and target states look like and should look like, you need to start to demonstrate early what your vision for the “new world” is. By demonstrating your understanding of current and target states early, even at a very high level, it will allow better communication with the client to validate your own understanding and to allow you to present your high level view to the client while instilling confidence that “you get it”. It’s important to use the right nomenclature when working with the client, so it’s important to understand the types of business terminology they use which may be specific to their business, and understand how to use it when presenting important concepts to them.
Early stakeholder and sponser engagement is important and it’s key to identify who are the most important people involved in the project. It’s important to develop early and ongoing relationships with them, and to understand their concerns and their view of how they want the “new world” to look. Part of this will be communication with different faucets or teams within the organization, including security, enterprise architecture, and more. It’s important to understand the maturity of the EA practice in the organization and work that into your methodology and operating procedure. All of this communication will help you to understand the lay of the land, technology roadmaps, technology constraints, and business drivers. It will be imperative to the success of your solution to have and refine this knowledge. Talk to the CTO, VP’s, Managers, and whoever it takes to get the knowledge you need. Be bold, identify what you need and figure out who to talk to to get what you need, and make sure you aren’t wasting your or your clients time. Be focused.
It’s important to always demonstrate a high level of cadence from the onset of your engagement through to the successful completion of the project. At the onset of the project or your business engagement, you should demonstrate a fast cadence to delivery, and keep up that pace. Make sure you are able to make solid decisions, but don’t waste time getting there. It’s important to also demonstrate quick wins and start doing this early on in the project. Quick wins can have a big impact to the project and demonstrate confidence to your stakeholders and sponsors while demonstrating early value to new initiatives. Make sure that this isn’t fluff, and make sure it’s something that is tangible and can be acted upon quickly to demonstrate early value. Continually apply this to your own methodology while also focusing on the big gains that may take longer to execute.
Of the upmost importance to being a consultant or any kind of service provider delivering solution architecture, is to be accountable for your deliverables while owning and controlling your process and your own rules of engagement with the client and project. Because you are in a business to business relationship to deliver architecture, you are responsible for your engagement, how you perform the work, the methodology you use, who and when you get the information you need to deliver, etc. It’s important that your process and methodology is defined and refined. I’ve been iterating on and refining my process and methadology for years, continually improving it based on retrospection and introspection and based on feedback I’ve solicited while also being honest with myself about what went well and what can be improved. Because client’s are engaging me and my company to successfully deliver solutions, it’s important that I bring my own refined processes and methodology with me to ensure things done and delivered successfuly.
Of course, there is a lot more to consulting and architecture than what is mentioned in this article, but the points I’ve indicated above, are very critical to demonstrate at the onset of a project, and will help set the narrative and expectations around architecture and consultant deliverables throughout the project’s lifecycle. I hope this provides some value to IT consultants, and specifically, those who work within a discipline of solutions architecture. Refining and documenting your own methodology and standard operating procedures is a crucial part of successful delivery in a B2B relationship.