It’s better to say when you don’t know.
Let’s face it: bullshit works. It’s often beneficial to give a confident, slightly vague response to a question than to waffle or look unsure. But as a PM, answers lead to decisions and work that might be a huge waste of time if wrong. So you quickly realize that it’s critical to let people know when you don’t know the answer to something, to prevent them from going down a rabbit with bad intel.
Know your goals and tenets.
Whatever project or product you’re working on, it’s crucial that everyone agrees on what the goals are in order to allow people to make good decisions under uncertain circumstances. Having clear goals is like having a map and a good compass while exploring.
Know your tenets. Tenets are different from goals in that they are how you do something, rather than what you’re trying to do. And there might be times where a lack of clarity of how you’re going to operate can lead to a difficulty in moving forward.
Always do the unblocking work first.
It’s often the case that other people can’t do their part until you do yours. Which means you better get that part done as soon as possible. Now, I’m constantly looking at the task list and thinking about which needs to come first.
Create the right sized task and group them well.
Products are nebulous. You have a basic sense for how they might function, but there are so many discreet elements, many of which have to work together. I’m lucky to have developers on my team who have worked on the tool for far longer than I have, and generally know how to pick off tasks that are right for their abilities and intelligently grouped together. Still, this is something I want to improve on – making the right kind of task.
Make the tools work for you
As a PM I use Bredmine as our bug tracking / feature development / general task management tool. I also am using Basecamp to have the communication seamless with clients, leads and stakeholders. It’s not so wise to introduce too much process but without ongoing conversations and some structure, it becomes really hard to measure progress.
Progress is paramount.
It’s incredibly important to track progress. The corollary to this is that backtracking or redoing work is the worst. For an instance I asked for some design work to be done and after I got it back, I realized I hadn’t been clear enough about what was needed. We ended up having to redo the work and I felt really bad for making the designer have to redo something because I wasn’t clear enough on my request. Every little thing like that causes the project to slow down and I have to be vigilant to not let that happen.
Watch for scope creep
Traditionally, the product I work on has been released in larger overhauls in a bit of a waterfall process. This sort of made sense in the past but because we had longer time spans between deploys, there was a tendency to want to add new features to the release, with the reasonable and accurate rationale being that it would be a while until the next release so let’s get it in there. This of course lengthened the time frame again in a vicious cycle.
Don’t be afraid to experiment with process
As a way to counteract the issues try something a little different: start 2 week sprints instead of 3 weeks, cut scope and ship *something*. The faster cadence is going to keep our morale higher, force us to be more disciplined, and help us to do ultimately do more.
Don’t forget about documentation
Functionality often trumps usability to some degree with the product I work on for complicated reasons, so remembering to build in time in the schedule for documentation, training and other issues is important. So I create and keep a fair amount of documentation that goes into the product. How it works, what’s changed, etc. Everybody wants their product to be as self-explanatory as possible.
Try to document in-the-moment decisions
I have been working with small cross functional teams and our work doesn’t always start with a massive brief. We usually have a list of stated goals, screens, and a general outcome we want. We have to figure out a lot along the way. I found myself making real-time decisions that I thought “I really need to capture this decision (and the rationale) for later on and I have found myself doing that with different ways.
from WordPress http://ift.tt/1x49BcB
via IFTTT
No comments:
Post a Comment