Project Management Made, Well A Little Easier
Saturday, July 26th, 2008
Posted by David Tedman
* This blog post is part of Invoke’s participation in the 2008 Vancouver Blogathon for Charity
As a project manager, I think it’s inherent that we are constantly distracted by the desire to create efficiencies in our development processes. Any extra time we can buy will add value to
project and gives us more time to focus on other important details. I
want to share the most important tool, um… weapon… OK, I started
this post with the idea to discuss the most important aspect of
development process, but now I’m thinking I should have written a post
about the most useful metaphors for project managers. We love em. I
sometimes wonder if we appreciate the well-crafted metaphor more than
the desire to bring clarity to the complex situation we’re trying to
describe. Well I know I do. OK next post is about useful metaphors
for project managers. What was I talking about again? Oh yeah,
constant distractions for PM’s.
OK let’s start… with a metaphor. If you’re a construction worker
your most useful tool is one that can be used for many of the tasks
you need to accomplish. A multi-purpose tool will also take up less
space in your tool box and because it replaces other tools you would
normally need to buy instead you can invest a bit of time getting a
good one. Our example will be for a website and our multi-purpose
tool is the Use Case. Once a project is past the “signing the
contract” phase, the next step is establishing what your project will
look like when complete and then meet that goal.
Let’s take a registration form on a website. It has 2 goals: Allow
the user to sign-up and don’t frustrate the user along the way.
Example. The user clicks on the registration button, gets to the form
page, fills in their first name, last name and email address, then
they hit the submit button below. This will save their registration
details to the database. The user will receive an email that confirms
their registration. If a field is not filled out, an error message
appears beside the field incorrectly filled out, with instructions on
how to fill in that field.
It’s a short description but it accomplishes everything it needs to
and forces the author to think of every detail. Once you have these
for all areas of the project in our case a website, you can use this
document from start to finish. The designers will use it to visualize
the site, the developers will base their functionality on it, and the
project manager will use it to take inventory of how complete it is at
certain stages of the process. The testers have a script to run
through test cases to ensure everything works as was signed off on.
When the Web site works as it reads, it’s done.
July 27th, 2008 at 7:19 am
Can the description of the task be that simple? I know that if you just give simple descriptions than what you will get is unfinished tasks. For example, in the case above, is it JS or Server Side validation for the fields? What is unique, the email, the first name and the last name, or both?
The description does describe everything you need, but it doesn’t cover all the details, which developers tend to like to miss (even when they know about them).
July 27th, 2008 at 4:44 pm
Admittedly it doesn’t cover the technical details to the level you describe, but it’s not necessarily meant to replace a technical spec. It’s great for having one document that serves as a guide to the client, designer and developer respectively. It keeps the goals clear and definitive.
Also if it describes exactly how a piece should work, there’s little for a developer to hide behind. If you have problems with loose interpretations of how something works, it’s time to adjust and get a little more detail into the document.