P2P (1): What is Necessary Right Now?
I have been working on a toolkit that will help out with “program management”. I wanted to jot down some things that I’ve discovered along the way that I thought others may find useful.
As I wrote this first entry, I realized that I had more to say than I originally planned. Thus, I’ve decided to split these apart into the first series on this blog. “P2P” stands for “Product to Program”. But, I digress.
The largest piece here is knowing that, yes, while you are establishing a whole big vision and set of things that you know are really going to help out, make sure you are clear on what’s short-term and what’s long-term. This is especially true if you are in a small, start-up environment. The last thing that’s needed is lumbering process and unncessary steps / tools that are going to bog down development and cause people to feel constrained and generally crappy. Blech.
With that out of the way, I’ve found that starting off with a simple set of goals is the best way to go. Yes, they can be lofty, but within the understanding of all parties involved in creating and using the tools being constructed. The communication of these goals, and the inherent vision, gets everyone on the same page and working together (fingers crossed).
Once you know what you want to do, the items that follow are a little interpretive. That may sound like a cop out, but it’s not — there are plenty of things that can be done, but it depends on the situation at hand. As opposed to using a specific example, I figured going through a set of questions that have helped me could be interesting.
- What is necessary immediately?
This first one can mean many different things. From my experience, it usually relates to having a bunch of stuff going on that key folks within the organization are unaware of, but should know about? If so, the solution is simple: write down what’s being worked on - the key stuff — nothing that a developer hasn’t touched and is still six months down the pipe. List creation is fun; a summary of each task, which can come right from your defect tracking system, a percentage of completion, who owns the task, its priority, and estimated timelines.
To be honest, if it’s the first time you are implementing this in a company, the list will go a long way — both up and down the line — and help out day-to-day. However, it’s critical to remember that once you’ve started to execute, expectations have been set. You will need to continue to execute regularly. We’re not talking every single day, in a regimented “same bat time, same bat channel” type deal. Casually works best, every 2-3 days, chat with those that have priority tasks being worked on.
Next post is question 2: How is the workload handled?
