Work flow defined by external factors and multi-tasking

Hello everyone - it is a pleasure to join you in this community!

I am trying to work out how to introduce CCPM and tameflow into our bid development process which involves developing tender documentation in response to a request for proposals. We work as management consultants, and one of the tasks of bid development is to assemble the team that will work on the assignment. The team consists of staff and external technical experts with specialist knowledge. Finding and securing the external team has a work flow that almost demands multi-tasking. The recruitment specialist will do research, write to potential experts, wait some days, review responses, negotiate involvement and rates, etc. and this might take a few weeks of elapsed time, but with only a few hours of touch time. It doesn’t seem possible to do it without multi-tasking, and there appears to be very little opportunity to improve flow with this work.

Have you any ideas how to do this? I am wondering whether securing the external team is part of full-kitting, or whether it is a MOVE (but if it is it is not possible to work on consistently). Or am I just trying to use completely the wrong tool for this type of task? I’d be very interested in thoughts of the community about this.

2 Likes

What you are doing is definitely knowledge work. Sounds like you have a project!

The bid proposal process is very difficult.

MOVEs are valid in this context. So is Full Kitting.

The trick now is to eat an elephant: one bite at a time!

Ciao

1 Like

Hi Grant, If you are looking to assemble a team I would highly recommend reading “Breakthrough project management”.

It is small book that you can read in one or two days but provides some very good insights on how to construct a team from scratch to achieve great results. (The emphasis is really on building new teams from scratch on a project by project basis. i.e. pulling in experts that potentially have never worked together in the past, in order to successfully complete a project.)

The book will probably change the way you approach technical experts and what you tell them.

Look forward to reading what others have to say about the multi-tasking and MOVE aspect of your question.

3 Likes

Hi @Grant and welcome to the TameFlow Community!

As @bvautier suggested, a CCPM wrapper around a MOVE could be an idea (see also Wolfram Muller’s works on this); and then you would use more conventional team allocation ways.

Check also the books by John Arthur Ricketts (“Reaching the Goal” and there’s a newer one too, I believe, but I don’t remember what it is called).

Maybe check “Dynamic Reteaming: The Art and Wisdom of Changing Teams” by Heidi Helfand.

Definitively take a service-orientation perspective. Model the bid process from end to end. First highlight just the activities that need to be performed. Then see who are the actors/agents that can perform - individually or collaboratively - those activities. But don’t assign them.

Consider an “orthogonal” Kanban system. Where the actors/agents are in a “warehouse”… [Crude image… but it works]. When the bid process arrives at an activity, you have a pull signal to the warehouse. If the person is there sitting on the bench, they get pulled into the activity. If not you have a backlog of pull requests for those people, that will be served at the earliest availability of the properly skilled person. If you buffer around the Herbie (of the bid process), these pull signals might be anticipated; so people become available “just in time.”

Of course you might need to deal with staff liquidity; and/or to increase the information sharing (informational flow) so you gain more flexibility in picking the people and assigning them to the work. But most important: let the work pull the people. Don’t push people towards the work!

Not sure if this helps - but without knowing the details, it is an exercise of imagination!

2 Likes

Thank you @DanielDoiron, @bvautier and @tendon - this is much appreciated. I’ll follow up the leads you have suggested. Just in case I wasn’t entirely clear, the external team I am referring to is part of the team for the delivery of the project itself, not for the development of bid.

One of the tasks of the bid development process is to find and secure the external experts. This process has some tasks that can be done in a batch (perhaps 4-6 hours of focused work), but after those tasks are done our bid development team needs up to 30 minutes per day over a 2-week period to monitor and respond to emails from the experts (they have to wait for external experts to respond, and when they do, they have to follow up with them to request information and related documents).

I can’t see any way to avoid the multi-tasking that this implies. They would need to work on other tasks (for other bids) during this waiting time (they cannot just sit round for 30 minutes of work a day blocking work on new bids) so they would get new work but have to keep going back to to monitor responses and respond to them in a timely way on the first bid, then on the first and second, etc.

Something like this simplified diagram - by day 5 they are working on 4 different bids at the same time which is exactly the same as they are doing at present.

I hope that makes sense. A lot of our work (not just this) involves doing some work and then sending emails or meeting requests and then waiting for people to respond. Responses don’t come, meetings get rescheduled, and work goes in fits and starts. This begets multi-tasking. These external factors interrupt continually.

2 Likes

I am with you. I had similar thoughts, when I first started reading the book, around what really constitutes “multi-tasking”.

Is it defined by the “type” of work, or the “tasks” themselves that are being worked on concurrently? What does concurrent even mean?

(I might have 10 tasks that all require exactly the same type of work done to them. It would not matter in which order I processed the tasks, or whether I worked on them concurrently, because essentially the end result is exactly the same. The other extreme is, tasks that are made up of multiple different types of steps. How do we define a task? Should a task only have one step? and the step involve only one type of work?)

How does this all relate to “context-switching”? (Which may be more fruitful to explore).

Just thinking out loud … The “monitoring” process looks like the real issue. Having dedicated days for writing and sending out proposals and dedicated days (or half-days) for responding could make things smoother.

I can see how this can become a mess with a lot of context switching once you have sent out 4+ proposals. Perhaps the “terms of engagement” you include in the proposals could help by setting the right expectations for the review process.

1 Like

OK. I see what you mean.

Maybe you could model this differently.

So not like ONE big monitoring task that is performed for say 30 minutes a day until all information is collected (and then finally unblock the rest of the work flow).

That 30 minute activity is well defined. So maybe you could model it with a separate task. One that gets added to your backlog in the morning, and you expect to manage it sometime during the day.

You are not multi-tasking in the sense that you are interrupting and then resuming a task; you are moving from one task to another, because you break it down into daily chunks, which presumably have known entry/exit conditions.

On your CFD this will look like a daily step-increment of your target line. See the post about Management of Extra Work. It would be as if you are adding a bit more of extra work every day, until you have collected/generated all the knowledge that is needed.

Would this work for you?

2 Likes

Thank you Steve, this is an extremely helpful insight. I have discussed it over the past week with my team and they understood the idea of daily chunks of similar work immediately. We’ve had our heads down doing the actual work over the past few weeks but while doing this I’ve been getting a better idea of how we can encourage flow in this work. I’ll give some updates over the next few weeks as we make progress, and may have some additional questions along the way.

2 Likes

This distinction between the type of work and the the tasks is very helpful. Thank you. In this case context switching is all about a shift in the type of work carried out. We have had very helpful discussions within the team over the past week about tasks that we should get done in one sitting before jumping onto something else, and tasks that can be bundled because they represent a type of compatible work. Thanks again for these insights!

1 Like

Thanks for keeping us posted. I can’t take any credit for the insights as I was myself looking for an answer. (but am glad the question helped :slight_smile:)

2 Likes

My understanding is that multi-tasking is primarily an issue at the constraint in the process. Enhancements made that do not affect the constraint will not contribute to improvement.

Per the diagram, the recruitment specialist is not the constraint. To have the recruitment specialist address only one workflow would likely be detrimental to the actual constraint. In a manufacturing context, what the recruitment specialist is doing is working on small batches to allow the workflow at the constraint to continue at pace and the additional set up and tear down effort is accepted and does not affect the outcome. I believe that the use of small batches in this way is subtly different from multitasking.

Consider the process as a whole and look for the constraint that limits throughput. Optimization outside this area will have minimal, if any affect.

2 Likes