Key Project Practices

The following is a short list of some of the project practices that have helped me maximize impact, while shipping on time and on budget.

Verification

Dog fooding. Throughout the project, I have the team dog food what we build. See Dog fooding (WIkipedia.)
5 customers. This is an critical check throughout the project that 5 customers stand behind the project. They key is these are 5 customers that actually use the deliverable.
Product teams stand behind / promote. Given that I create prescriptive guidance, it’s vital that the product teams can stand behind what I create. If they aren’t promoting it and using it to solve customer problems, then something is off.
Scenario Evaluations. Walking the scenarios and testing against scenarios is one of the most effective ways to verify the solution against the problem. I try to identify key criteria so the team knows what to look for.
Sign-off by key stake-holders. The key is to get everybody’s finger prints on it and to make sure they can stand behind it. It helps avoid the scenario where stakeholders shoot down the project.

Domain Analysis Artifacts

Question List. I create a list of what people “ask.” Knowing the questions people have, verbatim, helps me quickly know what problems people care about.
Task List (input for scenario frame). I create a list of what people “do.” A task list is simply a set of the tasks that users perform. Ideally, these are goal-based. As Alan Cooper might put it, “persona-based scenarios with goals.”
Scenario Frames. I create a Scenario Frame. Scenarios (or stories) are a simple way to organize the things that your users do. Organizing them in a frame makes them easier to manage and share. See Scenario Frames.
Real Problem Feedback. I find concrete instances of real problems. Finding people who actually share the problem helps.
Project Specific Personas. I identify the types of users, along with their context, drivers, and needs. Personas help with customer empathy. See Personas at patterns & practices.

Product Team Reviews

Product Team Reviews. Regular product team reviews help me keep everybody on the same page.
Whiteboard reviews. Whiteboard reviews simply mean rather than any formal slides, we simply review key concepts and ideas on the whiteboard. This is a lightweight way of checking and sharing information. They’re easier to organize because they can be done more ad-hoc.
Modular, incremental reviews. I try to engage the product teams along the way rather than a big bang at the end. It’s more effective and let’s us change course as needed. Most importantly, it let’s us act on the feedback.
Snapshot Reviews. I create tickler lists of points for review. Having a bulleted set of items to review makes reviews much more efficient and helps store and share state for a lot of information.

Execution

Exec sponsor. Having an exec sponsor helps the project over rough patches. Usually, the exec sponsor puts somebody on point as an escalation path and this helps with cross-group issues.
Cuttable scope. If you don’t have cuttable scope, your project is at risk. Cuttable scope means that when you cut something, you actually do gain back time, without messing up quality. To pull this off, it means having a good idea of discreet incremental chunks of value.

Communication

Internal project site. I’ve found that having an internal project site helps have a simple place to point people to let them know what’s going on with the project.
Agile customer project site. I find it helpful to have a simple place to share deliverables with customers. For example, this is our Visual Studio Team System Guidance customer site. It made it easy to share news, share releases and get customer feedback.
Team Wiki. I find it helpful to have a team Wiki to dump information as we go.

My Related Posts

Reader Interactions