Managing Tasks

[NC74]

Hi All

Been doing this for about 12 months now and I keep wondering on the most effective way of using plans and task/issues logs.

Currently I produce plans is MS Project that consist of deliverables grouped as work packages.

I also have what is basically an Excel To To list that captures smaller / unexpected / ad-hoc tasks that need to get done that may not have been captured at start of the project.

I was hoping to share some ideas on how we run and monitor our projects at task level.

Do people use a similar approach of a master plan and a separate task monitor? And if so to what extent to you use each document?

Or do you tend to use a main project plan that has all the smaller stuff added to it over the duration of the project?


Another related question, is at what level do you go to when managing ad-hoc tasks and issues?

I issue work packages to Team Managers who are responsible for on-time task delivery. There are obviously various issues encountered along the way that need to be captured and addressed, e.g. the product has failed a test and a new design needs to be released.

As project managers should we allow the engineers to capture and manage these issues in their own way, and we monitor and control at more of a top level where we don't care too much about the fine detail as long as the engineers can provide us with confidence that the work package can still be delivered on time / cost / quality?

I appreciate any feedback

Thanks

NC

 

[BNPMike]

If you record and track everything, you are a micro-manager.

You need to list all the things you need to understand how long the the project will take, how many people are needed, and what are the dependencies.

No project follows that plan, so you then constantly identify what needs attention and make a daily list of things you need to do.

No day follows that list so you actually spend your time reacting to what crops up during the day.

As with any management, your primary focus is the people doing things and whether information is getting spread around the team. Once you start fretting all the time about what is being done, you have become a supervisor. Get back to management by delegating and tracking whether team players are comfortable with how things are going in their area.

You manage exceptions and let your team execute the work.

 

[johnherman]

WBS - Work Breakdown Structure. WBS is the best way to track tasks at low levels, which can be rolled up to summary levels as needed. Whether you put the low-level WBS into MS Project is up to you. I do not carry low-level tasks in MS Project as they seem to be volatile (frequent changes, additions, deletions, etc); I use Excel. The Issues Log is the place where you track Issues. The Risk Register is used to track Issues which may impact the project. I also use Excel for these documents and I place them on Sharepoint with the appropriate access to the project team, stakeholders, PMO, and other interested parties.

====================================
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright

 

[NC74]

Thanks for the replies

I am in an environment where there has previously been very little focus on project management, and I am having difficulty with people accepting their responsibilities, including team managers and the project board.

I am finding that I have to manage at a level lower than I would like to / should need to in order to make sure things get done. At the same time I am gradually trying to step back to a level of detail that is appropriate for a project manager (as I see it).

I'm still trying to establish what an appropriate level of detail is for me to manage.

As an example,

I issue a work package to perform testing on a product.
I don't list Test A, Test B, Test C etc in my plan as I have asked the test manager to create a sub-plan with the detail included. My plan has a single entry to show 'Testing' where the end date is aligned with the testing sub-plan.

The test equipment is suspected to be inaccurate and there is a concern that the quality of the results is in question.
Do I log and track the equipment repair as an issue, or do I stay focussed on the testing milestone?

 

[JimmyTheFish]

Assuming the equiment is vital to the completion of the testing task and will affect the ability to complete it on target, you need to record the issue, identify the effort required to address it and the effect on the milestone. In addition, you need to understand the confidence levels of whether it will fixed in time to still hit the milestone (your confidence, not those doing the work who will automatically be over-optimistic). Armed with that you will be able to communicate the potential impact on the overall delivery, the effort being expended in addressing the issue, who is doing the work and the reporting schedule of doing the repair. The latter is essential to put into place as it is key to identifying the knock-on effects as soon as possible. The reporting of 'bad news' is always much better if the issue has been raised as soon as possible and you can illustrate the steps being taken to minimise the issue, but that the potential for schedule impact is possible.

Just my view!

 

[markprojectplanning]

Hi NC74,

I am new to some project managing stuff and your micro managing skills help me alot! I have also downloaded some ebooks to help for my managing career but you comments and suggestions here really help me a lot!


Mark