This is about inefficiencies I encountered when contracting.
I’ve worked as a contractor in the I.T. industry, automating tasks in the printing and prepress industry for the last 20 years.
Some projects were long-running engagements spanning multiple years.
Other times the task at hand could be completed in a few hours.
What struck me recently is how inefficient the ‘on-boarding’ process often was, and a how a lot of time and resources were being wasted.
In the worst cases, there was no on-boarding process at all.
In many cases there was some half-hearted, half-formal process with crucial bits left out.
In the end, it all boils down to communication, and making it easy to communicate.
Preparation is Half the Effort
The issues I encountered as a contractor could often have been avoided by some preliminary preparation.
For example, having a checklist of ‘things to provide’, without the contractor having to ask for them.
Hopefully the list of issues below can help making such a checklist…
What is the Goal?
Often the big-picture goal to achieve is quite fuzzy.
The information available might vague, using nondescript terminology, management-speak and interesting-looking acronyms
I’d find it helpful to see a value proposition for the project and my part in it. How will I contribute and help the project closer to its goal?
Some ‘Key Performance Indicators’ could provide a measurable benchmark.
What is Expected of Me?
As a contractor, I love a clear brief on what my task is.
Engagements often start with a game of ’email ping-pong’ where I gradually extract more and more information as I interact with people.
After a while, my ’email archive’ becomes my ‘knowledge base’. And that’s not really a good way to handle it.
There are easily accessible tools available that can help. And even though they are most often used in the I.T. industry, these tools can be useful in many other industries.
A task tracker or issue tracker is a software where tasks can be entered, and acted on, assigned, tracked. There are many of these (e.g. JIRA, GitHub,…).
And it does not need to be fancy. If push comes to shove, even an organised collection of Google Docs can work.
A ‘task ticket’ is a single record or document where the task-related information gathers, instead of being scattered over many emails.
It is clear who is handling the task at any moment, and it is clear when the task is completed or ready for the next step.
The task ticket contains enough information to determine when the task can be considered ‘done’.
Using a task tracker is no guarantee for efficiency, though.
It is a bad sign when task tickets consist of bulleted ‘shopping lists’ with ‘items to do’.
It is very common for this to happen, and it negates the advantages of the task tracker. It becomes impossible to track the individual ‘bullet points’ as they are now all swimming in a ‘pool of to-do’s’.
As a contractor, I try to educate the users who create these task tickets to try and avoid this.
At the same time, I’ll take it upon myself to split such ‘meta-tasks’ into separate task tickets.
Using a task tracker makes it clear what the action points are and who will act on them.
It also helps to have regular short meetings with the stakeholders involved to review the open tasks. Often, tasks will balloon out, and need to be split into separate subtasks.
Who are the Stakeholders?
As a contractor, I often get a very limited insight into the stakeholders who are involved.
I call this ‘the keyhole perspective’.
That often is detrimental, as these stakeholders often have a large influence on the project at hand, yet they are ‘invisible’ to me.
In a way, knowing all the stakeholders and what their interest in the outcomes is a Key Performance Indicator.
It’s always helpful to get an idea of the order of magnitude for the total budget for the project.
I’ve often encountered situations where the budget available was either unrealistic or not determined yet.
An estimate of the value of the benefits of the project outcome, taken over some sensible period of time can help determining an order of magnitude for the total project budget.
And based on that value, it becomes easier to assess if the project is a go/no-go/maybe-go.
Where is the Documentation?
It takes effort, but the effort of documenting pays back for itself many times over.
In the best situations, documentation is a prime component of the project, and a substantial part of the project budget is allocated for writing and maintaining documentation or manuals.
In many I.T. projects, documentation is treated as an afterthought. It is non-existent, not maintained, scattered, incomplete, organised inconsistently.
Mind you, it is always better to have outdated documentation than no documentation at all.
An outsider ‘coming in’ on a project is often in the unique position of detecting the holes in a documentation set.
Anyone who has been involved for some length of time will not spot the issues because everything is familiar. But a person in the process of being on-boarded will be able to spot things that don’t make sense.
When I find there is no useful information on record, I often offer my customer to document my learnings as to help others going through the same process.
Another related issue I often find is that there is some internal lingo and a set of acronyms in use within the company.
Normal English words are re-purposed to have some very specific meaning within the context of the project.
As an outsider, I then hear a lot of sentences that sound like English, but seem to be void of meaning.
Part of a good set of documentation should be a list of key words and acronyms that are commonly used and have specific meaning.
Who is my Buddy?
As a contractor, I love having someone available to me for questions and a bit of handholding.
This is unrelated to the ‘command hierarchy’. Team leaders are often overworked and overstressed and not often available for dumb questions.
Having a ‘buddy’ is very helpful.
How can I Measure the Effectiveness of my Contribution?
Left to my own devices, I often have the feeling I am throwing the results of my work into a black hole.
Is this useful? Does this help? Are there any issues I can tackle?
Especially during the initial days of the engagement having someone available to provide immediate and specific feedback is invaluable.
Also, explicitly defined KPI can be a tremendous help.
Are there any standards to adhere to?
In the case of software development projects, when it comes to writing software code, having a software coding convention helps make contributions from multiple team members more consistent. The actual coding standard is not very relevant. The relevant issue is having a convention, not what it says.
The same principles can be applied to other forms of information. When writing documents, a style guide is helpful and helps consistency. Things like templates can help.
Meetings are a necessary evil, and I like to try and avoid them if at all possible.
When I am developing software, I often find that there is a need for a demo of the software-in-progress. The traditional approach seems to be to call an (often online) meeting with a bunch of stakeholders and do a live demo with Q&A.
I find that it is often much more efficient if we can ‘decouple’. I do the demo all by myself, using a screen recording software, then send the pre-recorded movie to the interested parties. They can all watch it in their own time, and if things go a bit too fast, they can replay bits of the video.
We don’t need to hunt for a calendar slot that fits everyone involved.
Once they have seen the video, they can provide feedback, often via the task tracker system, or via a one-on-one video session, or via other means.
A task tracker can also help to make meetings shorter. Ask people to write out their ideas, requests, comments, feedback in the system beforehand. That way, they are encouraged to think things through, and ponder the ins and outs before going into the meeting.
It is like taking the notes before the meeting. The meeting can then be much more targeted.
Sniff The Air
An approach that worked well for me with on-boarding is something I dubbed ‘sniff the air’.
This might not translate well to other industries, but it worked quite well when I was able to use it for automation in printing and publishing.
Most of my customers are remote, in another part of the world.
There is a workflow of sorts, with human-performed tasks, and we want to automate that what can be automated, all within reason.
In automation, there is a law of diminishing returns: some tasks are so specific and have so many exceptions, complexities and variations that an attempt to automate them would end up costing more than the value of the savings that can be realised.
When automating in printing and prepress, we want to tackle the frequent tasks that are technically easier to automate, and leave the infrequent, complex tasks to a human operator.
From a cost-perspective, attempting to achieve 100% automation in a workflow is not often optimal.
There is a chicken-and-egg problem, however. As an automator, I very well know what kind of task is easy to automate and what is hard, but I initially know very little about the workflow at hand that needs to be automated.
On the other hand, the people working in the company know a lot about their own workflow, but they know not so much about what can be easily automated and what not. Often there is no documentation or procedure book, and the workflow ‘just grew’.
In those cases, it is very helpful if I can go ‘sniff the air’ for a few days.
The idea is that I sit in with people doing the work, looking over their shoulder, or even do some of the work myself, to get a very good idea of what the pain points are. Then I can come up with a list of tasks that are sensible targets for automation.
Show Me Some Examples
When automating printing and prepress workflows, a lot of the work involves taking documents, doing something to them, and handing them over to the next stage in the workflow.
A slightly less efficient approach which also helps me in my specific tasks is to insist on getting access to a good collection of sample files.
Often I can gain a good understanding of what needs to be done by inspecting a sizeable collection of sample files and manually made mock-ups of the desired end-result.
Lines in the Sand
This is actually a documentation-related issue.
Often it is not clear where the lines in the sand are.
For example: I might need to get access to a server to inspect sample documents, or to try and understand an existing workflow before attempting to optimize.
In some cases, my customers have fully-flegded test servers. These machine’s sole purpose is to be a test server, and it’s perfectly OK to poke and prod and cause issues with the server. There is a quick and easy process to restore the server as if nothing happened, and no ‘real’ processes are affected.
In other cases, my customers only have a single server, their production server. It is used for serving their customers, used for testing, used for development. When I am invited to probe it, I am actually touching the live server, and if I make a wrong move there can be grave consequences.
The lines in the sand in both cases are very different, and it is important to make the situation clear in the documentation provided.
The second case is dangerous and I would also try to allocate time and budget to set up a ‘safe’ duplicate of the production server, so any future tests and inspection can be done on a copy of the production server.
Ill-fitted Administrative Processes
One time, I was contracting for a large company. They were subscribing to the Ariba procurement software, run by SAP. They insisted that, as a contractor, I should use this system.
Being a one-man-band, I had to jump through many complicated hoops to register with the Ariba system. This system is ill-fitted for small companies like my own.
The funny thing was that as part of the enrolment process I had to provide a list of key positions in the company. I had to list my own name over and over as I registered the contact details for the CEO, CFO, CTO, Financial Controller, Head of Administration…
Getting registered was a pain and getting invoices out and paid was a pain as well.
It took months of real time and a lot of time and effort on my part just to be able to send an invoice in a manner that was acceptable to the system.
The lesson I learned was that next time a large company wants my services, but at the same time, they want me to jump through hoops and put up administrative roadblocks, I’ll just walk away and say ‘No thanks’, and I’ll concentrate on serving agile and flexible customers instead.
Related to this are having to deal with unreasonable payment terms.
Large companies often delay payment 90 days or even more, which is not OK when it comes to working with contractors.
A related trick large companies often use is to separate their administrative departments from the rest of the company.
Often, my customer is a certain department or entity within the larger organisation, and they are not holding the purse strings.
To get paid I need to deal with a separate entity, the administrative department. Part of their job is to make things cumbersome in order to delay payment as long as possible.
My remedy is to discuss this beforehand, and negotiate reasonable payment terms with my customer, while making sure they have the leverage to lean on their administrative branch to fast-track a payment.
If that is not possible, I walk away.
I once managed to force a large company to provide me with a gopher person just to fill out my time-sheets, because they were making it so complicated that it was hindering my ability to do what I was hired for.
I Cannot Be Bothered
A lot of potential customers (often government) will never be able to use my services.
As a consequence of a number of sensible and legal reasons on their part, there is a vicious circle in place, where in order to bid on a possible project, one needs to respond to a complex RFP.
This takes a lot of time and effort with limited chances of success. I never bother. From my angle, the return-on-investment for the effort put into an RFP is very low, and I am lucky to have many better customers to choose from.
As a result, those contracts go to established companies who are good at handling RFPs. They don’t need to be very good consultants. As long they’re good at handling RFPs, they get the contracts.
Furthermore, in my opinion, RFPs often don’t work. I have almost never experienced a successful project where the outcome matched the original project brief.
There is often a stark difference between what my customer wants, and what my customer actually needs.
I am good at my job, and part of my job is to look at the issues from a number of different angles, then help figure out the real needs and make sure they are met, rather than the imagined needs.
Here’s a curse that applies: “May you get exactly what you asked for instead of what you needed”.