There’s always the low-tech way of managing a process, too


One of my colleagues had a problem with content management. I've changed the underlying scenario but the principle is the same.

Is there a way to require that someone other than the author of a proposal sign off before the proposal tracking system accepts it? We had an issue where somebody wrote up a proposal, and due to a miscommunication, the proposal coordinator thought the proposal was ready and submitted it prematurely. This happened to another team in our group, and we want to make sure we don't make the same mistake.

Another colleague explained:

This is a people problem, not a technology problem. One way to work around it is to tell the proposal coordinator, "Don't submit the proposal until I sent you email that says it's okay to submit the proposal."

I agree that this was a people problem, but the offered solution suffers from the same miscommunication problem as the original. The proposal coordinator might ask, "Is the proposal ready?" and the author responds, "It'll be ready tomorrow." The next morning, the proposal coordinator submits the proposal assuming that the author's response meant "Submit it tomorrow," when the author actually meant "You will get an email message from me tomorrow when it's ready."

My colleague responded that the technique still has a single point of failure: An error by one person (the proposal coordinator or the proposal author—you decide who is at fault) results in the proposal to be submitted prematurely. We want to make sure two people sign off on the proposal before it is submitted.

I proposed a method popularized by Henry Ford: The assembly line.

  • Author writes proposal. Places proposal in Location 1.
  • Proposal is reviewed by reviewer A. When it passes review, it is moved to Location 2.
  • Proposal is reviewed by reviewer B. When it passes review, it is moved to Location 3.
  • Proposal coordinator picks up proposals from Location 3 and submits them.

With this scheme, every proposal must be approved by both reviewer A and reviewer B. If reviewer A fails to approve the proposal, then it remains in location 1. If reviewer B fails to approve the proposal, then it remains in location 2.

This is another one of those simple low-tech solutions: Instead of putting all proposals (complete and incomplete) in one location, the location of the proposal represents its approval state.

Of course, you can add more bells and whistles to this technique. For example, you can allow reviews in parallel by having Location 1 mean "unapproved", Location 2a mean "approved by reviewer A only", Location 2b mean "approved by reviewer B only", and Location 3 mean "approved by both reviewers." I'm sure you can come up with other tweaks. (I'm assuming that the proposal file format doesn't support custom fields like "signed off by".)

Comments (15)
  1. RobertWrayUK says:

    This reminds me of the Maker/Checker (en.wikipedia.org/…/Maker-checker) technique that banks use, or at least they're both of a similar ilk.

  2. nathan_works says:

    workflow, man, workflow..

    (OK, since we don't know when this blog post was generated).. But Sharepoint does a great job of this.

  3. JerryR says:

    Very similar to kanban concept devised by Toyota for lean/just-in-time production.

  4. Arnshea says:

    One of my first gigs after grad school was putting together a web-based app that did exactly what you're talking about.  In this case the department was responsible for password resets and various permissions.  Certain requests had to be routed to certain people for their approval with various emails indicating state transitions and a few loops to allow for the occasional screw up (ala Jill rejected Mike's request but should have approved it).  Throw in a final state for "provisioned" after the work has been done.  I'm sure this kind of workflow applies to a ton of other business processes.

    I'd never thought of it as an assembly line but you're spot on, it's very much an assembly line-like process.  The thing being "produced" if you will is whatever you submitted the request for – in your example getting the proposal submitted, in my case getting the request provisioned (e.g., password reset or permission to access file system X).

  5. Boris says:

    Isn't the point of software to simplify workflow? What's wrong with having software require you to do something instead of telling people to follow a process and have them ignore it because it "takes too long"?

    For example, when I started my current job, I intended to organize every email I receive at the time I receive it. Guess what? There are now 1140 emails in my inbox compared to 159 in my largest folder. I'm lazy and would benefit greatly from some sort of automated solution (it's not as simple as filtering. I need to sort emails by project, type, resolved status, etc).

  6. mike says:

    A problem with status-based location is that it means everyone who has an interest in the item has to know what status it's in in order to find it (e.g., for further review). Not a problem when you have 3 documents, perhaps, but doesn't necessarily scale all that well. The reason I know this is is that we use this system (in DevDiv UE, among others) to track art requests for documentation. They enter the system as requests, go through a "in process" stage, a "review" stage, and then a "final" stage. Problem is that the original submitter (a writer) doesn't necessarily know whether the graphics person has gotten to the request, and ends up having to sift through potentially thousands of requests to find his or her specific request. (In reality it's not that dire, since we can search by ID, but that's the point — you have to search for something who's ID/title you actually know.)

    Consider an analogy — you drop your car off for servicing. You come back and you have to go to a different counter to ask about it, depending on whether they've even started on it (pending request), are working on it (in process), or are done with it (ready). Only you've dropped off a dozen cars over the course of a month and so have 300 other people.

  7. James Schend says:

    Boris, maybe this won't work for you, but it works for me. I just gave up trying to organize emails, and now I get everything I need by either:

    1) Copying the email file into the project folder it applies to

    2) Searching my inbox

    Anyway, my inbox has tens of thousands of messages in it, and I seem to be able to get at information the same as everybody else, so I'm happy with it.

  8. Nicole DesRosiers says:

    Mike: Isn't the great thing about virtual documents that they can have more than one location at a time?  Let's say that Reviewer A and Reviewer B both have huge piles of stuff, and you need to find your item.  Since it's a virtual document, it can be in both Reviewer A's pile and in your "Things I Submitted" pile.

    Problem solved?

    (Could require specific software, but could also be handled by, say, tagging.)

  9. Arnshea says:

    RE finding email.  I gave up on organizing email a few years back.

    Search/Windows Search/Windows Desktop Search FTW

    kind:email has:attachment sent:"last week" "I'm buying lunch"

  10. Joshua says:

    This is why it's so hard for software engineers to beat a *good* paper process.

  11. jasomill says:

    Off-topic, but amen to the "search-based organization of email." For the past decade, after reading my email, I've put it all in a folder called "Saved," which now contains over 30,000 messages. When I need to find something, I search. Funny how Google came up with the same basic idea when developing Gmail. I probably have

    "How do you find anything?" I'm often asked. Never been a problem (the few times when I've really needed "all the emails relating to a particular such-and-such," e.g., for litigation purposes, it takes only a few minutes to do so; why optimize for this uncommon case?). On the other hand, I've noticed the people who "organize" their email into innumerable subfolders are the ones who have the most trouble finding old messages (mainly because they never bother to learn about their email package's search features).

    Email, like most nontrivial forms of information, doesn't admit a natural* hierarchical structure ("I need to sort emails by project, type, resolved status, etc.", Boris writes above), and attempts to "shoe-horn" such a structure are often, at best, a waste of time.

       -jtm

    * In the sense of "there's one, and only one, obvious way to do it," or, if you prefer rigor, in the sense of category theory — the "obvious way to do it" depending, in this case, on the circumstances. Incidentally, this is why relational databases work much better, in both theory and practice, than hierarchical databases. It's also why object-oriented design is so hard to do well.

  12. KatieL says:

    I just grep across directories of flat archives to find email as well. I've got a decade of email in there; probably hundreds of thousands of messages. It's reasonably fast — and it's more capable of handling that bulk than any of the UIs I've found.

    The main way it could be improved is if grep supported "X within N lines of Y"… but then I guess that's what Perl is for :-)

  13. David Walker says:

    I wish I could tag an e-mail message, WHEN I receive it, that it will expire on a certain date and should be deleted on that date.

  14. James Schend says:

    David: you can use a mail action to do that right now… I guess I don't understand what feature you're asking for?

  15. Arnshea says:

    @david, hmmm, a poor man's way of doing that in outlook – drag the message to the task pane, prepend DELETE MSG – to the subject and set the date to the date you want to delete it.

Comments are closed.

Skip to main content