Building the complete project design is a bad job. On one hand, you want to get an exact depiction of what shape is being done when. On the other hand, you get to make a program that is manageable (read: not overloaded with a bazillion items).
Unfortunately, business is messy. No matter how well your intentions are, slippery little tracking problems inevitably creep in.
In this post, we feel at a few common project planning issues, explore different approaches to solving them, and hopefully help you gain the end of a better (if not perfect) project plan. Problem #1: Accounting for non-project work in your schedule
Applies to: Anyone who has overhead tasks on their plate.
Solution A: Reduce their daily availability down to the list of hours they will probably influence on design work.
Pros: The agenda will stretch tasks out over the allotted time, presenting a more realistic depiction of what they can get done within their designated availability. Plus, you`ll have fewer items in the plan, which keeps things simple.
Cons: The overhead will be uncategorized and untracked, at least as it relates to the relief of the design work.
Best for: Teams that are focused more on results than reports.
Solution B: Reduce each person`s daily availability down to the issue of hours they will probably make on task work (as in Answer A), but likewise make them track time on a number of shared "ongoing tasks." (The "ongoing tasks" can be unassigned and un-estimated, and anyone on the team can add them to their timesheet.)
Pros: You`ll even get an exact depiction of project task completion dates, but you`ll also get an approximation of where all the overhead time is going. That can help everyone understand the full workload better, and thereby inform business decisions.
Cons: It`s light to leave to cover overhead work, since it doesn't look on anybody's list of active tasks.
Best for: Teams that rely on information to measure efficiency, where tracking time is partly of the polish and recognized by everyone on the team.
Problem #2: Building workflow into your project schedule
Applies to: Teams that make complex approval cycles.
Solution A: Create a labor for each step in the approval cycle, regardless of how little it is.
Pros: Everyone`s part in producing the project deliverable is defined. Schedules will be more precise because more granular tasks are being included in the plan. Key steps are less likely to be lost because they`re listed out in advance.
Cons: The project plan can sometimes get out of control, with a tons of "micro-tasks" to manage, assign, estimate, etcetera. Team members viewing the program can be bothered by the absolute number of things they want to keep track of.
Best for: Teams that bill clients based on time tracking data, and/or who rely on a tightly-managed plan for holding on top of many individual deadlines.
Solution B: Create one task assigned to the individual doing the major chunk of work, then transfer it to the approver (or whoever the following person in the workflow chain is) when the handoff needs to make place.
Pros: Keeps the project plan simple and slow to manage.
Cons: Schedule dates may break and briefly throw off the plan. For example, let`s say a designer estimates 15-25 hours of influence on a website design. After 6 hours, the first rev is through and she passes it off to the business owner for a light review. For a point of time (until the inspection is gross and the job gets passed back to the original owner), the remaining effort will be stuck into the reviewer`s schedule, pushing out other dates in their plan. Plus, the petty people in the workflow chain don`t account for their parts of the tasks in their own plan, creating a potentially unrealistic schedule for the process they do own.
Best for: Fast-moving teams that don`t need the charge of an overly-complex plan. They`re willing to weather some short-term fluctuations in schedule dates as farsighted as the main tasks are being managed well. Problem #3: More than one individual is responsible
Applies to: Teams where collaborating on individual project tasks is par for the course.
Solution A: Create a separate task for each person doing the work*.
Pros: You can order just how often each individual will be conducive to the overall effort on the task. Plus, the project can be prioritized appropriately for each individual (it may be the #1 priority for Mary, but #3 on the listing for Jen.)
Cons: Where to store project collaboration information (like documents and comments) can be unclear. If you`re reporting or charge against the work, the two (or more) tasks will want to be aggregated.
Best for: Tracking-centric teams or in cases where the hours spent on shared tasks are significant (as compared to a little consultation that lasts 15 minutes).
*You might be thinking, "Microsoft Project lets me assign two owners to a task. Why can`t LiquidPlanner do that, too?" The understanding is this: sticking with one owner per task is the most accurate way to get the result of the task (and how much effort is associated with it) on each individual`s schedule. Tying two peoples` work together doesn`t fly when they won`t be running on the task at the same time, which is much the case.
Solution B: Designate one of the task owners as the "principal" owner. Let the secondary collaborator track time against the task owned by the principal owner, but don`t admit it in their list of project tasks.
Pros: You`ll consume fewer plan items to manage. Plus, overall responsibility for the project is clear, even if ownership is shared.
Cons: To get an accurate project schedule, you`ll get to make certain the secondary owners have reduced availability that reflects how much "overhead" time they spend collaborating. Team members should also give it a pattern to use collaboration features to support each other in the loop.
Best for: Teams where project communication, flexibility, and openness are paramount.
Each of these problems is, at its core, a mutation on one question: how much detail should you admit in your program? And at the end of day, the solution depends on your team`s culture and tracking requirements. To avoid ongoing friction, it might makes sense to give a candid discussion around the tradeoffs of more vs. less detail with stakeholders early on the in the project planning process.
What other challenges is your team dealing with when it comes to building out a design plan and tracking work against it? Share them in the comments! Maybe we`ve got some different approaches for them, too.
No comments:
Post a Comment