How to Migrate from Task Management to Project Management?

Question

The company in question is currently micromanages task assignments, updating people's calendars several times a day as to what they should be doing and when. They feel the need to put more structure into their workflow but are having trouble making the conceptual leap to more of a project-based workflow e.g. where tasks would have a due date, at the least, and people could decide on their own as to when to work on it to get it done.

Any ideas on how to assist them in this transition?
They feel the pain but can't see the bridge to a solution.

FURTHER INFORMATION They have one PM who acts mostly as a traffic manager. However, the pm is trying to move to greater structure - wants more building a house, rather than putting out fires.

There is no methodology at this time or pm approach. The team is servicing client requests as they come in. Some requests are for larger, longer-term projects such as putting together a new marketing brochure. Some requests are shorter, like putting up a new picture on a website.

It is a relatively flat organization. Owner/Manager, PM, account exec, group of creatives and developers.

Answer 1

Strange, but talk about taking "looking through a microscope" to a whole new level. In this case, instead of breaking it down further, I'd say they need to do the exact opposite and go back to the big picture.

In other words, all of these task assignment contribue to some goal (I'm assuming). What is this goal and can it be translated to a project? From there, work out the deliverables and assign it to a team member.

From that point, the typical PM methodologies would take over (depending on what they want to use).

I know it's easier said than done, but I'm keeping my answer a bit broad as I am making a lot of assumptions being made about their existing process.

Answer 2

I believe a Kanban style implementation would fit perfectly. Have the PM move from managing tasks, to managing a prioritized list of user stories based on the client's requests. Get the team together once a week or so to break down the user stories into tasks (This should be the team, not the PM doing the breaking. You could also simply have the team break a user story when the PM is ready to put it on the board). The PM controls which user stories' tasks go on the board, and the developers worry about the order in which they are completed, and who completes what.

The selling points of this implementation:

• It doesn't change much over their current flow, and doesn't require any new technologies (other than a whiteboard).

• The PM still gets to manage the order in which customer requests are completed by managing which user stories' tasks get placed on the board, but he no longer has to micromanage how those tasks are completed.

• The team becomes responsible for breaking up user stories into tasks. This will involve them more in the process, break the user stories in a manner that makes sense to the developers, and relieve the PM.

• Kanban-style should support the different lengths of customer requests nicely, rather than having to try and force them into a fixed length timebox.

Answer 3

It sounds like the company being described does not trust their employees to figure out how to break down their projects into bite-size tasks, and thus it is doing it for them. Perhaps using a piece of software like Asana would help. The management could define the high-level and medium-level goals, and let the employees break down those goals into discrete tasks. Because Asana allows everyone to have a real-time view of what is going on with the project at a detailed level, that would give management a chance to see that the employees do actually know how to manage their own work, and would also allow them to see the detailed tasks that each employee is responsible for.

It's certainly possible that the problem runs much deeper than not having the right project management tools/software, but something like this may be a step in the right direction. Both sides would be giving a little: management would be allowing their employees more autonomy, and in return, employees would commit to exposing their detailed tasks (which they may currently manage in their own way) to management.

Also, there are surely other tools that could be used in the same way, but I just happen to be familiar with Asana (and it's free).

Answer 4

Micromanaging is a simplistic "fix" for an issue like poor quality work, not staying on budget or schedule, perceived inefficiencies of workers, etc.

So look for the root cause of the problem that causes the micromanagement and use that to develop a business case for a project-based workflow over "today's" approach of micromanagement. Do your best to quantify the pros and cons in dollar terms and let them see precisely how much value they can add.

Just make sure that the business case is fair, open, transparent and fact/data-based.