7 Steps to Workflow Nirvana

Ideas often come in interesting packages — a multitude of shapes and sizes.

I work with people to improve their business processes, moving them from analogue (paper) to digital (bits), helping to reduce data loss, error, and duplication. I have a knack for solving intractable problems.

Over the next few paragraphs I’ll provide you with some ideas to help you tame the worst business processes.

But I’m getting ahead of myself…

While at an event in Sheffield, I introduced myself to a fellow attendee, and after explaining a bit about what I do she began to regale me with the tale of a fascinating and somewhat alarming problem she once had while working for a major high street retail chain.

Understanding the process

As I understood things, during the summer months, certain parts of the store had a strict dress code, and signage was required to make a polite request (no vests or shorts).

However, before anything could be printed, a couple of bureaucratic stages had to be navigated:

  1. there was a minimum budget requirement of £8;
  2. 5 signatures were required (signature 1 was needed before signature 2, and so on and so forth).

As you might imagine, this process of gathering signatures was glacial, somewhat difficult to orchestrate, and — as the woman explained — prone to failure as the paperwork, because of the flimsiness of the stock, often got blown from a desk by the merest breeze.

So that would be the loss part of what Octane works to reduce, along with duplication and error, a point I made to the woman, which earned a sardonic chuckle.

I’m guessing the minimum spend was intended to reduce costs and avoid needless activities, but after a quick calculation, things didn’t quite add up.

So imagine a scenario where this 5-level sign-off process is performed 5 times a week per store for various activities across 100 stores. Each time the process is performed, there’s an average loss of 48-72 hours (a figure gleaned from the discussion with the woman).
rusted-pipes

Defining the ideal business process

Now, let’s imagine a simple secure piece of software with a sign-in for the stakeholders: managerial signatories; and floor managers. After an initial investment of 5-8 hours of basic training it’s up and running.

A sequence of ‘signatures’ is required, and after the stakeholder signs into the application, he or she does nothing more than read the request before clicking either an “Approve” or “Reject” button:

  • If approved, an automated request is sent to the next person in the chain.
  • If rejected, the person who sent the request could then ask for further clarification, a process captured by a messaging component within the application.

Running the numbers

Let’s assume our ideal business process shaves a modest 12 hours from a number of workflows bound by the same rules. So that’s 12 hours, multiplied by 5 times each week, multiplied by 100 stores.

Our little application would have saved them 6,000 hours.

Imagine what would happen if we applied the same streamlining to mission-critical processes that are vital to operations?

I know, it’s that commingling of terrifying and amazing!

pipe-ends

Optimising a workflow

So now you understand how structured processes might lose time, let’s explore some ideas on how we might fix that.

  1. Reduce the number of stages. If you have 7-10 stages, that’s at least 7 different places for something to go wrong, and then you or someone else has to figure out where and then how to fix it. So examine the workflow with a mindset of simplification, liaise with the stakeholders, be on the look out for loss, duplication, and error and bring them down (elimination is the goal, but not often feasible — we are human).
  2. Keep the processes small and manageable. If your workflow must consist of 7 stages, keep them compact and understandable. Some other idiot (you, I’m guessing) has to read over the documentation in 6 months’ time and make sense of it.
  3. Document everything. Use something like Google Docs and share the documentation amongst the team. Use the ‘Track Changes’ feature, to follow who wrote what, why, and when.
  4. Automation. If feasible, automate your workflow. Don’t be afraid of a hybrid analogue-digital series of processes (paper and bytes), so long as you’ve documented everything and each analogue stage has a person responsible for it. Whatever shape the workflow takes, make sure the data it creates is in digital and not analogue format (at some point, you might need to analyse the data).
  5. Limit the number of people involved. I often have to explain to clients that design is not a democratic process. So unless you’re a multinational corporation, you won’t need to vote each time someone proposes a change. An ambassadorial approach is often required to deal with those protecting the borders to their fiefdoms, and then there’s the oft cited refrain: “But, we’ve always done it like this!” In each case, take the big-picture approach and be brave!
  6. Restrict the number of signatories. The fewer the number of chiefs, the more time the indians have to — you know — do the hard work. However, build in an audit trail (via the documentation in point 3), so the decision-makers know what happened and when.
  7. For goodness sake, communicate! If you suspect there’s a flaw in the process, speak up. If someone has a suggestion, listen. Neither of these two things should be a major problem (or another time vampire) if you’ve followed point 5. While this might sound obvious, engage with the people executing the processes because they’re the ones doing the hard work, so they know better than anyone.

Perhaps now you understand why I’m passionate about ideas because it’s often those in the smallest packages that are the greatest of gifts.

First published on LinkedIn.


How to respond to failure. Or, after the problem came the procedure.

Encountering problems and making mistakes is a consequence of life, business, and everything else — and unavoidable. But the value is in how you respond to them.

As I said on Twitter this past week:

I’ve found that the best lessons in life — by far — are those where you learn how NOT to do something.

But still, as good as vicarious experiences are, they only get you so far.

In the beginning, there was the mistake…

By gum, was it a doozy! I’ll spare you the gory details (because they are — for the most part — irrelevant) but it was less a bug and more an infestation in the code. In the grand scheme of things, it has caused problems for our schedule, but the Under Cloud remains on course.

Stripping the whole problem down and tracing it to its source, it was — as these things often are — a failure to communicate, which resulted in team members and myself labouring under the assumption that something was when it wasn’t.

And then came the procedure…

So how did I respond?

We’re using a number of things to manage what we do. As a team of 3, we don’t need a lot, but we find that Slack and Trello are enough to keep things together, although we often find things said and done become lost inside the whirring cogs of the communication machine!

I created a list in Trello and added a card entitled: “Deprecated”, within which I wrote the following description:

“Here are all of the parts, components, and libraries of the application that have been deprecated, and what they’ve been superseded with.

Please update this card as and when required, but also refer to it, too!”

Some might argue it’s just a patching of holes, while some might claim it’s only of any use if people follow the procedure, but I would counter by saying that’s life, business, and everything else…


Quite simply, clients count on quality

Quality is one of those things a business needs to get right early and quickly. Quality of service is not optional, nor is it interchangeable (or to be confused) with something else, like quantity. So would you impose a statute of limitations on the quality of the service you provide? No, you wouldn’t. And neither would I.

Of course, it wouldn’t do for everyone to be the same. At least that’s what my mother used to tell me. But then my mother didn’t run a business. As sage and sound as her advice often was, some things are an immutable prerequisite, like quality.

OK, let’s talk specifics — specifically, where a statute of limitations exists as a legitimate cut-off point for quality. Here I’m thinking of a time-limited warranty, like you get with physical goods, such as home electronics, food and vehicles.

In this kind of situation, you expect the guarantee of quality to fade over time, as the physical product ages, and is exposed to real world knocks, scuffs, tumbles and inexorable decay.

So that’s the physical time-limited quality issue out of the way. I’m sure we all agree on the legitimacy of warranties, yes? Now, I had an unusual conversation yesterday, one that forced me to think of the obvious in a way that, at least for me, is a constant I wouldn’t dream of tinkering with.

There’s no statute of limitations on quality

I was asked if, say, six weeks was a reasonable period of time, after which a client could no longer legitimately request fixes to software that myself, for example, had developed for them. As you can imagine, that threw me.

There were technical issues here — which I suppose we could consider as clauses — that needed addressing, as they were key players. Ultimately, they amount to an exercise in finger pointing, if I must be lazy about this. My reply was:

“If there’s a bug in your code and it’s your fault, don’t expect a client to observe a statute of limitations — they want a fix!”

And that’s only fair, and that’s where the technical clauses emerged — who made the most recent changes, to which files and when. However:

“If the client made any changes in or around the area of the fault, I’d make them aware of their liability.”

Which essentially highlights to the client the possibility that they will have to pay for those “fixes”, should any be required.

Now, don’t get me wrong, I’m not laying any blame on the person who asked me this question. After all, each industry has its own customs and practices. To me though, common sense wins out every time, and customs and practices be damned.

So I guess what I’m saying is, software doesn’t come with a warranty, and don’t expect a client to think otherwise.


How best to deal with the needs of leads

So you got a lead. Good for you! Warming that lead up is crucial. Fudging the numbers, or scaring them with big ideas can just leave them feeling cold. So what do you do? Scale those big ideas into bite-sized chunks and think long-term.

I’ve been thinking about project management a lot recently (and doing a lot of project management, also), which you’ll probably have detected as you’ve skimmed through the headlines to my earlier articles. In some ways, this article is a continuation of the last, which you may want to read, to give you some background.

Be the voice of trust

As with almost every facet of business, trust is a mandatory quality and not some interchangeable attribute you can substitute, by being cheap or quick. So when someone comes to you for your services, it’s as much about people management as planning and pricing — people won’t buy from you until they’ve bought into you.

Being eager is great, but there’s always the danger you’re coming across too strong and a little too eager, bordering on insincere. After all, we’ve all witnessed the say-yes-to-anything sales man and woman at work, and clearly the experienced amongst us have these encounters drifting forward from the back of our minds.

And here’s where I go slightly off at a tangent, but it’ll all make sense, trust me. And I begin with a confession — I don’t pitch for work.

Octane doesn’t do the pitch thing!

The problem with pitching for work is that you’re sort of relying on one thing while skipping several others. In the first instance, you’re assuming the brief you’ve been giving is worth the pixels or paper it’s written on. And then latterly, you’re skipping the all-important initial meeting where you initiate a Q&A, to disentangle need from want.

So when that brief arrives, I’m usually to be found shaking my head, wondering just what the hell I’m supposed to make of the whole thing. Worst thing is, the emphasis is nearly always on cost, in that they equate cheap to be synonymous with being good. Well, we all know where that road leads to.

I’m guessing that, by now, you see where I’m going with this, right? Ask the right questions, and keep asking the right questions. If required, and as I’ve said before, don’t be afraid to ask the obvious questions.

What I’m really getting at is, I either do things right and in their correct order, or I just don’t want to do them at all. And since I’m eleven years into the big game, I have the option of indulging in that particular luxury of choice.

Project priorities

Certainly from my point of view, the various requests and briefs I receive are either a cursory examination of needs, or technically incomplete, which is to be expected as their authors are unlikely to as technically competent and literate as I am. Either way, none of this is a problem for me. But, it’s at this stage that the problems can surface.

Curb your enthusiasm

“Yeah, I can do that.” being the reaction of many, upon reading through a brief. “This is easy.” they add, enthusiastically, quickly diving into a lengthy and detailed document of how they’re going to transform the humble and basic needs of the prospective client into some all-singing, all-dancing cavalcade of features and bells and whistles.

Overload. That is the word most appropriate and often to be found on the lips and in the minds of the recipients this tome of a document sent back in reply to the author of the brief. Overwhelming. That’s another word, very similar to the first.

Needed now, Next time, Nice to have

Being objective is something that cannot be emphasized enough. What the prospective client may think is vitally important may well be of secondary or tertiary importance. So prioritizing those requirements is essential a function as just about anything else. In fact, getting things in the wrong order could be a project-ending event.

What I do is take those needs, break them down into what I see as their right order and then sort them again, this time by, well time. You see, any good project has a deadline. And since time is the final arbiter of all things, good or bad, by shuffling those needs around, based on which are Needed now, we can then sort the rest into those that are required Next time around, with the remainder being the ones that would be Nice to have at some later date.

Once you start thinking and then acting this way, everything then sort of looks better. Modular. Now there’s a good word, and appropriate, too.

Cooking up a feast of features

You’ve taken the needs of the prospective client and chopped, hacked, sliced and diced them into bite-sized chunks that are much more digestible by all, delivered to them in an appetizing assortment of textual delights!

OK, enough with the food theme, you get the idea. The point is, you’ve given dates their requirements by which you’ll deliver demonstrable evidence of your good work, packaging your ideas with their own, adding a quality of depth to a project, that allows them to structure their time and budgets accordingly. Keep in mind, the author of the brief might not be decision maker, so your reply may well be a sales letter to their immediate superior.

Packaging your project estimates

We’ve covered a lot of ground, here. So I think this calls for a break-down.

  1. Think strategically, and long term.
  2. Keep the technical talk to a minimum, or at least keep it simple.
  3. Since this is a lead, you’re still very much selling your self and your services, so write accordingly.
  4. Break everything down by their respective priorities, and sort those requirements into Needed now, Next time, Nice to have.
  5. And finally, since there’s no small measure of consultancy being thrown into this, fold those activities into your estimates.

So there you go, a neat list of suggestions, to keep you on your toes and help warm up that lead. Of course, these things are dynamic, but I’m sure you’ll not go too far wrong if you keep these suggestions in mind or at least at hand.


11 steps to building the perfect project

While we’re always eager to strike new ground and get working as quickly as possible, planning is the be-all and end-all of the success of any project. As the saying goes — fail to plan and plan to fail.

I’ve seen eagerness get the better of judgement. I’ve seen people lunge straight into the work side of things and be content to worry about the details afterwards. I’m not one of those people.

The best laid plans…

A few years ago, I took a former client to County Court because they were simply unprepared to let me plan a project they way I’d recommended from the very beginning. And then when things went wrong, the client simply would not accept responsibility for their own failure and refused to pay.

Now, taking my own advice, I chose to invoice the client in stages, mitigating the losses I suffered. However, because of their incessant adding of new bells and whistles, the latter stage of this failed project ballooned and the whole thing simple couldn’t be maintained.

Building the right foundations

So what’s the solution? As usual, the solution is best served when we first describe the problem in simple terms. During the County Court proceedings, I needed to make the case against the client as simple, clear and unambiguous as possible. And I did that by way of an extremely simple analogy.

Imagine you’ve been contracted to build a house; a small abode, not too dissimilar to a bungalow. You dutifully ask the client all the right questions, to which you receive clear answers and the work commences with you laying the foundations for the house.

But then the client realizes the true value of the land and changes their mind — now they want a twelve story apartment block. But they also want all of this work doing for much the same price you originally agreed to for the bungalow. And worse still, on the same plot of land on top of the same foundations.

That was my predicament described in painful detail. Sat across from me in the County Court room, the now former client squirmed with growing discomfort while his colleague looked away impassively and shame faced.

Yes, I won the case, but I’d rather not have been there in the first place. As clearly as I’d explained to the client these issues from the very outset, they were unprepared to heed my articulate protestations concerning the perils we were destined to endure, as we would eventually face each other down across a very solid wooden table in some anonymous County Court room somewhere in Yorkshire.

So again, what’s the solution? There’s no way of over stating how important trust is in all of this. And trust is a two-way street. Also, trust your instincts. I didn’t. Why? Because while I was prepared to plan ahead, I was the eager fool. So matters weren’t helped by the fact that I was being lied to by the client, which my instincts had informed me of, but I continued working with the client regardless.

Trust isn’t absolutely essential, so long as both parties adhere to what’s been agreed. Yes, that’s some kind of trust, but not the right kind. As we all know, trust is a hard-earned quality of any relationship, and for some, it’s simply not a given they can be trusted.

Laying the foundations of a successful project

Sadly, there’s no magic trick to managing client expectations. But there are a number of things you can do help insulate yourself from the death of a project, or to work towards keeping a project alive when circumstances are at odds with you and your carefully laid plans:

  1. Once the client is happy with using your services, reply to them either by post or email with a confirmation of the brief (or at least what you both agreed on), with a copy of your terms & conditions, and ask them to reply to this correspondence, which will be your proof of receipt and a tacit acceptance of your terms & conditions. And in a court of law, this acknowledgement is as good as a binding agreement between yourself and the client.
  2. In addition to agreeing on what your activities will be, the client has commitments, too — enshrine their commitments in the brief, also.
  3. Once they have agreed on their commitments, don’t be afraid to chase the client down when they’re being tardy. Yes, this can be an annoyance for them, but it’s preferable to seeing the project languish, stall or possibly even fail.
  4. Be thorough, objective and assume nothing — don’t be afraid to ask the obvious, as you’d be surprised just how many times the stark staring obvious gets over-looked!
  5. On the subject of being thorough, keep complete and precise notes of everything, and I mean everything — every form of correspondence, every conversation and every decision or moment of indecision. What you know is vital, and can serve as an audit trail, should things go wrong. Also, in keeping such detailed records, you increase your value to the client, as they may then rely on your for such things.
  6. Know who all of the stakeholders are in a project, and know what their roles are. As much as you can, limit the number of stakeholders who are charged with defining your work schedule. You do not want to commit to work that you may not be paid for.
  7. More importantly, don’t be afraid to say “no”. Seriously, Saying “yes” is often synonymous with “I don’t know, but I’ll try”, and that’s as good as a lie.
  8. Break the project into deliverable and demonstrable stages, invoicing at each stage.
  9. If you foresee problems, explain them to the client as clearly and as early as possible.
  10. Don’t allow yourself to be railroaded into doing something you know is either illegal or not in the best interests of the project.
  11. If the client begins to make additions and / or amendments to the project, assess their potential for disruption and be prepared to move them to the end of whatever stage you’re working on, or even the end of the project. While the client may have you believe those additions and / or amendments are vital, be thorough, objective and assume nothing — and stick to the plan.

Sometimes, the needs of the project are far greater than the wants of the client. Articulating that to a client takes a deft touch that not all can summon up the words for. So clearly, perils remain.

That aside, armed as you now are with various ways of staving off project failure, the only thing you may lack is the guile, the gumption and the sheer guts to ask those obvious questions and to say “no” where and when appropriate.

Beyond that, you should now have the right idea about how to manage a project and all of its attendant delicacies and details. So good luck!

Do you have your own project tips, tricks and things to avoid? If so, why not share them in a comment.