Project vs Product vs Team; which to use for work planning!
If you are managing work in an IT environment you may have come across this challenge; how do I plan and keep track of the work when I have to juggle Project initiatives, Product development and work allocation to Team members.
Small to mid size IT team managers are often in a position of having to juggle all three dimensions of work planning. Agile is great but at its core it is a work planning process that focusses on a Team of people. How do you provide a complete picture of the state of each of the products that the team is managing?
Prince 2 and other PM frameworks are also great but if you don’t have a dedicated project team how do you keep track of all the different requests for changes to the various Agile teams?
The role of the elusive Product Owner is a fantastic concept but where will you find that magical unicorn, for all the different products you support? If you can’t find that person, how will you keep a product backlog for all the products you support and make sure it’s kept up to date?
Firstly these are 3 different dimensions of work planning. Each of those dimensions requires a different approach. If you try to plan on all three dimensions at once you are likely to fail, or at least get gray hair sooner than you need to.
Projects are by their very nature cross functional initiatives created to achieve organisational benefits. They are established because achieving the outcome within one team is not realistic. As such an IT manager will have a number of project managers calling on their Teams time for a number of initiatives at any given time.
Products in the IT world are generally systems. In the Agile world we create backlogs and issue registers for products. That is how we keep track of what changes have been requested and what issues have been discovered in that product.
Teams are groups of people who work together (obviously). Most often teams are defined by the organisational hierarchy and have a line manager in charge. In Agile we may have cross functional teams with a Scrum Master but contention over resource capacity allocation often prevents that from being an option. In Agile the teams will do work planning every fortnight or so to clarify the priorities. Without Agile the line manager will allocate work to the staff or the staff will accept work from stakeholders. In the latter case prioritization and requirements clarification is left up to the staff member alone.
Secondly, if you pick any one of those dimensions and manage all the work though the lens of that dimension you will be able to find a plethora of tools and frameworks to plan and track the progress.
However, if you manage a team who oversee a wide range of products and deliver to many different projects at the same time how can you achieve the same?
The answer is not easy. The project has to keep track of the project milestones and outsource the deliverables to the technical teams. This means that the project manager is responsible for planning and tracking progress against the project milestones. To make this task more manageable the teams have to provide an interface for the project manager to be able to hand work to the team and get the outcomes delivered.
In order to keep track of the team’s commitments the manager or scrum master has to create a team backlog of work. This backlog then progresses and deliverables get handed off to the requestor when completed. This team backlog allows the team to know what they have committed to and where they are up to. Fortnightly work planning makes the task of managing the backlog much easier.
Finally, you also need a product backlog to keep track of the state of the different products. This is where the requests should go and where the technicians should update their progress. Project requests would generally go into the product backlog. Most of the time projects require changes to products so planning with a product mindset tends to be the better option for the IT managers and scrum masters.
Lastly you need to bring together the work out of the backlogs and into the team backlog. Ideally the tool you use can do this for you by adding a layer of team management on top of the product backlog, allowing you to plan the work of the team but link the work items though to the product backlogs. If your tool does not do that you may want to keep the team backlog separate but avoid duplicate data handling as much as you can.
In the end the best way to manage the work is by focusing on maintaining well groomed product backlogs. Project and team planning will then use these product backlogs to add their requests and track progress.
