Here's one method to fairly allocate tasks within an embedded systems design team.
In some work environments, daily work tasks and their priorities change constantly. This ongoing reprioritization prevents team members from completing planned project tasks because they've expended insufficient effort on the planned tasks and too much effort on the unplanned tasks. Rather than pretending that project plans are fixed or expecting that all planned tasks will be completed “by any means,” it is more beneficial to deal with reality so you can manage the ballooning workload and reprioritized tasks before they jeopardize the project.
Many techniques and methods attempt to tame the project-management beast by preventing or ignoring change. Using the technique I'll describe here, you can:
- Plan project effort weekly.
- Plan daily work based on task priority.
- Add high-priority tasks at any time; any resulting resource overload will be immediately obvious.
- Easily identify any planned work that won't be completed (or is at risk), immediately assess the impact on the project schedule, and make alternate plans before the project schedule is severely disrupted.
- Track actual effort against planned effort on a periodic basis (weekly, or whatever frequency is appropriate) and easily identify schedule variances along with the cause(s) of the variance.
The ultimate goal is to manage human resource workload. A reasonable daily workload estimate for an eight-hour work day is six hours due to “human factors.” Because we aren't machines, it's reasonable to expect that people are not 100% effective all the time. In an eight-hour work day, we're only productive for four to six hours. Here are a few of the reasons for this:
Bio breaks– Everyone needs to take a breaks, stretch and move, drink, eat, and use the restroom regularly throughout the day.
Distraction– It can take ten to 20 minutes to get back into a productive/creative “flow” after an interruption, and we are interrupted almost every 15 to 20 minutes by phone calls, “urgent” e-mails, and ambient activity.
Fatigue– Working overtime on an ongoing basis may be detrimental, as we're less productive and are more prone to making errors (that consume additional time and other resources to resolve) when we're tired.
Multitasking– Switching between multiple concurrent tasks often leads to overload and lateness for several reasons:
- The interrupted tasks take more effort to complete than uninterrupted tasks due to the distraction factor (mentioned earlier); it takes “set-up” time to switch between tasks.
- Regardless of the additional effort for interrupted tasks, each individual multitasked task takes more calendar time to complete due to the other intervening tasks.
Community–Human beings are social creatures who interact with those around them and may also have family matters to balance with work. These interactions include “hallway” and “coffee-pot” conversations, e-mail, phone calls, and so on. Communication and natural curiosity are good as they increase the overall knowledge base of the organization. These are distractions nonetheless and shouldn't be overlooked in planning.
Scenario: Imagine that everyone has a stack of chips (like poker chips). Each chip represents about one hour of effort. Because it's understood that people aren't effectively “on task” for eight hours per eight-hour work day, a “reasonable” amount of work to plan for is six hours per day (or six chips). If someone is given more than six chips of assignments for completion in one day, the risk that some of that work may not be completed can be identified visibly and immediately.
Note that it must be understood that six hours is a planning guideline, and shouldn't be considered a quota or maximum daily workload. The goal is not to encourage people to go home after six chips have been completed in a day (a minimalist attitude). This attitude would be detrimental to the organization.
The chips, each representing about one hour of effort, have different colors representing different levels of task urgency:
- White– meetings.
- Blue– regularly scheduled project work.
- Yellow– critical-path scheduled project work.
- Red– unscheduled “urgent” work.
Each chip is labeled with an indication of the project or task that the effort was expended on, and also indicates the name of the person expending the effort. For planning purposes, assume a total of six hours (chips) per day.
Cast and crew: the roles and responsibilities are:
Authorizer (A)– Creates project resources (hires, fires, (re)allocates resources among various projects), manages budgets (creates chips), and is accountable for corporate goals of cost, quality, and schedule.
Project Supervisor, or Responsible (R)– Allocates resources granted by A to specific projects, assigns tasks to project team members (D), is responsible for meeting project goals of cost, quality, and schedule.
Project Team, or Doers (D)– Performs the tasks assigned by R. Responsible for meeting task and project goals of cost, quality, and schedule within the constraints of the resources allocated by R.
Project Manager (PM)– Maintains project schedules, collects and records chips for daily effort expended, compiles and tracks planned verses completed project work, helps identify and track project schedule risks.
On a weekly basis, R and PM meet with D to determine their planned activities for the week. Chips are given to each D as their planned activity for the week:
- A white chip is given for each hour of scheduled meetings. Fractional hours count as a whole chip; two half-hour meetings would result in two whole chips. The chip is labeled with the project or activity's name (training and department meeting are examples of nonproject related meetings.)
- A blue chip is given for each planned hour of noncritical-path project work.
- A yellow chip is given for each planned hour of critical-path project work.
- A red chip is maintained only if it is left over from the previous weekly planning cycle.
D's responsibility is to complete the assigned, prioritized tasks with quality results. At the beginning of each day, D reviews his or her store of chips from the weekly planning session and chooses the most appropriate six chips to complete for that day (his stack). An example stack is shown in Figure 1, followed by the planned day in Figure 2. D completes this daily planning in a matter of minutes.
Presumably, daily planning begins with selecting the scheduled meetings (white chips) for that day; these white chips would lay on the bottom of the daily stack.
Next, D selects the most appropriate red, yellow, and blue chips to complete for the day. The total plan is six chips.
Based on the other chips in their store, D may decide that one or more meetings and scheduled tasks must be missed to accommodate other, higher-priority chips.
If there's a need to change work-task priorities or add urgent tasks (red chips), the requester must obtain the necessary red chips from R. This re-planning is shown in Figure 3. Adding red chips to D's stack results in a quick replan of the remaining daily effort. Again, D may eliminate meetings and other planned project tasks from the stack to accommodate the new tasks. D quickly identifies which tasks are now at risk of not being completed that day and alerts the PM to assess the impact on the project schedule. This new plan is shown in Figure 4.
If PM determines that D's revised task priorities may critically affect the project schedule, it's R's responsibility–not D's–to find another D to complete the at-risk tasks or to reprioritize the tasks in D's stack. R may collaborate with other Rs to find a D in another project team to complete the at-risk tasks. R may also authorize the risk. In other words, by rescheduling the at-risk task for the next day or some other time, R may “take the risk” that the project schedule will be affected.
If no Ds are available to complete the at-risk tasks, R may escalate the matter to A. It's A's responsibility–not R's or D's–to procure the necessary resources or reprioritize tasks across all project teams to complete the at-risk tasks. Conversely A may authorize the risk against the project schedule.
At the end of each day, each D “drops” the chips that he completed for that day in the appropriate receptacle labeled for the day of the week.
Logging and evaluation
On a weekly basis (or other appropriate interval), PM tallies the tasks completed by each D and compares the planned project effort against the actual project effort expended. Because all unplanned tasks (red chips) are also tallied, if a project is delayed, PM also has the evidence to account for the delay–the unplanned tasks (red chips).
PM monitors the project effort expended against the plan, identifies imminent risk, and escalates to R and/or D as necessary. PM also identifies whether any scheduled project task has become critical and if the chips associated with that task should therefore be “promoted” from blue to yellow. After tallying the chips, PM returns the chips to R for reuse in subsequent planning sessions.
Note that it must be well understood that the effort required to report the collected information won't be used to judge whether D has completed “enough” work in any given time period. Using the collected information in a punitive way would cause D to report what's expected rather than what actually transpired, and thereby invalidate the information and eliminate the PM's ability to identify project risks.
It's also reasonable for the organization to assume that if D completes all planned daily or weekly efforts before the end of the day or week, D will seek other project work; perhaps off-loading another D's stack or seeking additional project work from PM, R, or A.
Tracking additional tasks that a D completes is easy and should be used to recognize people for their contributions. In addition, if PM recognizes that D is doing too much (such as more than 10 chips per day on an ongoing basis), PM may recommend that D resume a normal balanced schedule before his health is adversely affected.
Measurables should be checked periodically. Daily effort expended against each project task is the tally of the number of associated chips submitted (dropped off) at the end of the day by each team member. The actual daily project-task effort verses the scheduled effort is available from dropped chips at the end of each day. And the daily work-plan risk indicator, in general, is more than six chips in any team member's stack.
Although this simple technique may appear to be silly in some respects, it addresses several serious problems that may have severe consequences to successful project completion with minimal overhead effort. The goals of managing resource allocation, work-effort tracking, and identifying risks to the schedule are accomplished by the appropriate project personnel. It may also bring a game-like aspect to an otherwise tense environment.
Finally, it's important to note that this proposal isn't intended to monitor actual work completed. It is solely intended to help manage human resource over allocation and reallocation, to quickly assess and manage any potential affects to the project schedule, and to facilitate the reporting of actual project task effort expended.
The white, blue, yellow, and red chips are “work” or “effort” chips. You could add “performance” or “behavior” chips:
Green chip– for incentive/appreciation/recognition, granted solely at the discretion of the manager or supervisor. Green chips can be traded in for incentives such as:
- Cafeteria pass (meal or refreshment).
- Meal gift certificates (elsewhere).
- Movie tickets.
- Other gift certificates.
The black chip
The black chip can be used for demerits; it cancels a green chip. Continued behavior or performance issues may result in R or A issuing a black chip. When D redeems green chips, any existing black chips may be deducted. (This system, of course, can't replace the legal steps a human resources department must take in cases of poor performance.)
Chips empower the “Do-er” (D) with some push back when new “most important” tasks supersede the previous “most important” tasks. The chips also enable project managers and supervisors to more easily track and control what is and what isn't getting done. For instance, here's a typical interaction:
“Joe Engineer” is hunkered over his computer keyboard working diligently while a stack of red chips teeters next to his coffee mug and other stacks of blue and yellow chips are pushed off to the side with cobwebs on them.
Someone in a suit standing behind him says: “Joe, I need you to make one little change for me. It shouldn't take more that an hour or two.”
Joe (without even turning around): “Go get two red chips from my supervisor.”
Suit: “I already asked and he won't give them to me; he says you're too busy. Come on! This is REALLY important!”
Joe: (again without turning around, motions at the stack of red chips): “So is this stuff. Bring me chips for my stack.”
Suit stomps off with a cloud of dark smoke rising from his ears.
A while later, two people in suits are standing behind Joe; the original Suit, and Joe's supervisor.
Supervisor: “Joe, this is a real show stopper that needs to be taken care of immediately. It looks like it shouldn't take more than two hours of your time. Here are two red chips. Can you handle this?”
Joe (turns around smiling with his hand open to receive the chips): “Sure. No problem.”
Joe plops the two new red chips on top of his stack, thinks for a few seconds, and pulls two red chips from somewhere near the middle of the stack of red chips. He turns back around and hands them to his supervisor.
Joe: “This will not get done today.”
Supervisor: “WHAT?! That's mission critical! It HAS to get done today or we can't release the product to the customer!”
Joe: “That's what I told you yesterday when you put those three new red chips on top of my stack.”
Supervisor: “Yikes! You're right. I didn't count on these new chips today. I'll go see if someone in another group can take care of these. Just work on those two new chips right away. Thanks.”
Joe: “No problemo; you're the boss.”
Ben Sweet has been engaged in developing real-time embedded software and systems for automotive and industrial applications since 1987. He currently is a principal engineer in the software engineering department at Lear Corp. and an adjunct faculty at Lawrence Technological University. Sweet holds an MS in electronic and computer control system from Wayne State University and a BSEE from Michigan State University. You may contact at .