Managing a complex work plan that spans multiple projects and teams means always being able to decide what's more important. And there's always a decision to be made. Telling your development team to focus 35% of their time on one project and the rest on another is a sure recipe for both projects not finishing on time. Keep it simple, break the plan into smaller chunks and decide what's more important.
This is how Gigantt tackles prioritization. Instead of maintaining complex resource allocation schemes, users of Gigantt define goals and prioritize them. A goal in Gigantt is just any task in the work plan. When you mark a task as a goal, Gigantt analyzes the entire work plan and considers all the tasks that have to be completed for the goal to be reached. For you nerds, it's like a reverse DFS of the work-plan graph. Okay, enough nerd talk, let's see an example.
Kramerica Industries has two products: Widget and Cajiggre, and there's a work-plan for a few weeks ahead.
Jerry is in charge of Widget and Kramer is in charge of Cajiggre, and as long as that's the case there's not much to prioritize. Work happens independently and in parallel. Things become more interesting when there are shared resources between products. So let's throw George into the mix as QA Manager. George has to test each version of each product before it can be shipped, and there's only one George... Let's see how each product's plan looks now.
Jerry's plan looks OK. He does the development and George does the testing (and shipping) right after each version is finished:
But Kramer's plan has a few delays in it. For example, George is busy testing Widget 1.0 when he could be testing Cajiggre 2.0:
At which point a decision has to be made, which product is more important. Since Widget appears before Cajiggre in the work plan, Gigantt will automatically give it preference when assigning resources. Whatever appears on top is considered higher priority. This is true for simple tasks as well as for whole projects and it's the simplest way to prioritize in Gigantt. But what if Cajiggre 2.0 is actually a top priority for the company? We need finer-grained control over priorities, not just between products but also between individual versions of each one. We achieve this by marking all of the ship tasks as goals.
Just toggle the little star icon for every task that should be considered a goal:
If we then click on (prioritize) we see an ordered table of all the goals in our work plan:
If we drag "Ship 2.0" to the top, as the video below shows, all the tasks leading up to "Ship 2.0" get rescheduled so that "Ship 2.0" completes as early as possible.
Same thing can be done with individual tasks, not just entire versions of the product. Since a goal is defined as everything that must happen in order for a given task to finish it's entirely possible to define multiple goals in the same projects. Notice that goals can also overlap (share tasks).
 |
| first task is shared by both goals and thus has top priority (red) |
Whenever there's any contention about a shared resource, managers can easily define any task as a goal and prioritize it to settle the dispute. They can also play around with priorities to see how much it effects the finish dates of each goal. Instead of allocating resources in advance to various teams and then fighting over who "owns" the lab this week, only goals are prioritized and everything else is derived from that. Prioritizing goals is less confrontational than prioritizing teams or entire products.
What I like best about Gigantt's goals is how clearly the organization's priorities are conveyed to the teams. It's hard to get confused by that table above. Everybody knows where their efforts should be focused.
