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?
Proportion of time spent project planning vs project actions
-
begeland
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
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
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
And here is Duncan's explanation!
http://www.projectsmart.co.uk/pareto-an ... -step.html
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:
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
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:
- Must do now; high priority problem impacting the business.
- Do this month; medium priority needs fixing, but can wait to be scheduled in.
- Do next three months; low priority to be fixed when the opportunity arises.
- Not going to do; close bug and provide an explanation to the requester.
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