I approach consultancy as a short term custom engagement where I work directly with the client to achieve a set of aims.
- It is custom because the aims are unique to each client
- It is short term because the aim is to help the client take action, rather than sell them additional staff/time etc.
Typical approaches for a consultancy engagement:
- Health Check - an investigative overview into our current situation to identify risks, issues and actions for improvement
- Targeted Improvement - given a known issue, identify ways to improve the situation and experiment with solutions
- Quick Start - given a particular technology, have someone experienced, implement the technology against our application to determine feasibility, identify risks, and create a foundation to build on
- Mentoring / Coaching - work with a team to pass on experience and implement some improvements to create a more effective working process
- Knowledge Sharing - short visits to show & tell, and identify ideas for improvement
A client relationship might involve multiple consultancy visits spread over the course of a few months or even years. With each visit taking the form of one or more of the engagement types above.
Example Engagement Types
Health Check Reviews
A health check review is a short term engagement to give you confidence in what you are doing well and identify improvements with discrete steps to take action on.
- what are we doing well?
- what are our current issues?
- what do we have blocking us?
- how do we compare to the industry?
- what can we do better?
Working with the team to look at their approach to Software Development and Testing, not just automating.
- communication processes
- where is the waste in the process?
- an outsider perspective to challenge “we can’t do that here”
- knowing what the end game looks like to help you identify next steps to move forward.
Strategy and Process Improvements
- help you understand the risks and issues with your current processes and suggest alternatives, with reasons why the alternatives could make a difference in your context.
- point out what you are doing well, as it is important to build upon the existing areas that are working.
- help you prioritise automation between the different architectural layers. You don’t want to see all your automation at the GUI, and we want to help you spread the automation across your technology stack.
Example Engagement Lengths
Example: A Long Term Consultancy Relationship
A company wants to improve the development and testing approaches in one of their departments. The consultant is engaged to help, and will do so by visiting the company for 1 week per month, for 12 months. Each visit has agreed aims, and agreed teams that they will work with. e.g. on one visit the consultant might work with a team for four days to help improve their use of a particular tool, and might spend a day with another team to knowledge share a particular approach to software development. Each visit would have specific aims and mix different types of consultancy within the visit.
The engagement is long term to provide consistency in advice and to allow check in on progress and implementation from earlier visits and offer ongoing advice on the improvements and actions being taken.
Example: A short term Health Check
A company is early in their implementation of a particular approach. They want to know if they are doing it correctly and what they can improve. The consultant spends a week with the company, interviewing staff, pairing with team members on work and experiments, reviewing results and code, etc. At the end of the engagement the consultant will have created a set of notes which are used to present on the findings.
The engagements are custom:
- sometimes a formal report is important so additional time is spent writing up the notes and creating a more formal presentation
- engagements have varied from working with a single team, two teams, even up to eight teams with a Knowledge Sharing approach
- the aim is to work with client to improve and identify actions, not work independently and create a report
- conducting experiments and doing, works better than talking and reporting
- the aim is that knowledge is shared with your team, rather than gained by the consultant
- at times the team provide the hands on tactical skills and the consultant helps with strategy
How Consultancy Works
All my work has been conducted for applications heading to production, and often against tight deadlines.
I provide feedback during the consultancy, either through workshops, progress meetings, or early access to my notes and reports.
When a final report is required, it pulls together the incremental findings and recommendations, with any additional observations from seeing the total set of information in the report. I produce documentation incrementally throughout the process and ensure that the document quickly adds value, rather than pads out the time of any engagement.
Common success factors for on-site visits are:
- appropriate staff available for the required time during the visit
- fixed time
- agreed aims
- agreed deliverables
- progress reporting and updates during the week
- available environments and tools so no time wasted on setup
- pairing rather than working alone
Remote Consultancy Works
I can work remotely. When I do, and where code has been involved I also tend to create a walk through video where the code is talked through and explained, as well as a written report. I also host screen sharing meetings online to keep you informed of our progress.
Do you want help to improve your Software Development?
Let me know how I can help you.