Proportion of time spent project planning vs project actions

This forum is for members to share and gain knowledge of Project Management. Got a question about project management? Need help with a problem? Wish to offer tips and advice? Post here.
Post Reply
davek
New Member
New Member
Posts: 1
Joined: Tue 26 Mar 2013 5:23 am

Hi,

I am running SAP system with 300 users together with my team leader and we have support from an external consultancy. We have an issues spreadsheet to track the status of projects, bugs, incidents, change requests etc. The goal is to have an overview so that we can prioritise, plan work and assign tasks to ourselves or the external consultancy. Also we want to have enough information so we are not blocked even if one of us is off work. We also link items in the spreadsheet lines to other files which contain details, documentation and log history of the issue.

At first, we had 20 - 30 issues and the system worked well. I spent 10-20% maintaining spreadsheet and logs and rest of my time executing actions to solve the issues.

Currently the spreadsheet has 150 issues and growing. I could easily spend 100% of my time maintaining and updating the spreadsheet.

Every morning I face the same quandary - should I spend time updating the spreadsheet to give us a better overview of the priorities for the day or should I simply take a intuitive guess and start resolving one of the issues. If I spend most of my time updating the spreadsheet, I am not directly helping business. If I jump in and work on an intuitively chosen issue, I maybe neglecting higher priority issues.

Has anybody else faced and overcome this dilemma?
User avatar
begeland
Expert Member
Expert Member
Posts: 173
Joined: Sat 09 Mar 2013 11:46 pm
Location: Las Vegas, NV
Contact:

davek-

This is an excellent question on a very important - and all too common topic. I'm going to start with a blanket statement that the daily planning and prioritization you are doing is critical. Why? Because as you and your team work to resolve issues, you want to be sure that you're hitting the most critical ones first.

I once took over a project that was near deployment. All that was really left was break/fix testing to get through about two pages of issues. The problem was, it seemed that every issue we fixed created a new issue...sometimes two or three issues. We really weren't prioritizing at first, we were just stepping in and tackling the issues by going down the list. Once I stepped back and mandated that we first prioritize, we were then better able to plan what expertise we needed to bring in so that we could better resolve the issues systematically and move forward. It took a lot of work, and yes we went over budget doing it, but we finally narrowed the list to a manageable few - small enough that we could comfortably deploy the solution, call it 'done' and work with the customer post-deployment to resolve any lingering issues.

I wouldn't skip that planning and prioritizing effort...but it sounds like you should possibly bring in some help to get you through all of the issue resolution.

Brad
User avatar
kwalford
Global Moderator
Global Moderator
Posts: 301
Joined: Thu 08 Dec 2011 1:34 pm

I understand that there is a dilema on whether to action this issues themselves OR maintain the logs correctly, but Pareto Rule technique might be of a benefit here.

And here is Duncan's explanation!

http://www.projectsmart.co.uk/pareto-an ... -step.html
User avatar
dhaughey
Site Admin
Site Admin
Posts: 462
Joined: Sat 19 Dec 2009 4:39 pm
Location: London

Hi Davek,

In practical terms you could think about implementing a bug tracking system. My team use JIRA from Atlassian, which has streamlined our bug tracking and resolution process. I have assigned one person in the team to triage bugs and assign them to resources. We prioritise bugs into:
 
  1. Must do now; high priority problem impacting the business.
  2. Do this month; medium priority needs fixing, but can wait to be scheduled in.
  3. Do next three months; low priority to be fixed when the opportunity arises.
  4. Not going to do; close bug and provide an explanation to the requester.
JIRA manages the priority of bugs, makes it easy to see them in priority order and manages who they are assigned to. Bugs can also be assigned to teams.  I only get involved if the person triaging is not sure what to do with a bug.

The system is fully email enabled, so resources receive email messages when new bugs are assigned to them, the status changes or an update/comment is made.

Using a system like JIRA certainly takes the leg work out of prioritising, assigning and monitoring bugs.

Hope this helps.
Duncan
Post Reply