Dylan Smith

ALM / Architecture / TFS

  Home  |   Contact  |   Syndication    |   Login
  71 Posts | 0 Stories | 89 Comments | 29 Trackbacks

News



Archives

Post Categories

Blogs I Read

I wanted to take a few minutes to talk about the project management / tracking / estimation methods I use.  Over time the processes and tools I use have changed quite a bit, but the way I've been doing things recently really works well for me.  The primary tool I use to manage a project is a feature list.  Similar to a product backlog from SCRUM (although we don't do sprints...or I suppose you could say we do a sprint for every feature).  The feature list is constantly evolving as we discover new requirements, or new feature requests are received.  I maintain this list using a Sharepoint list on our project site.  The feature list is prioritized (stack-ranked) in order from highest priority to lowest.  We don't give each feature a priority from 1 to 10 or some similar ranking (low, medium, high, etc), instead we sort the whole list according to priority relative to the other items on the list.  This prioritization is done as a group with the project stakeholders, and we hold a weekly meeting where any new feature requests are reviewed and their priority relative to the rest of the list determined.  One of the nice things about using this method, is that we never have to refuse a feature request, or somebody requesting to expand the scope.  Every request will be added to the list, then it's up to the group to decide where it should be prioritized.  Even feature requests that are just wish-list type stuff, that we know won't get done in the near future can still be added to the list, they will just be prioritized near the bottom.

At our weekly meeting, in addition to reviewing and prioritizing new feature requests, we also review and update (if necessary) the "go live" point.  This is the cutoff point in the feature list that all the stakeholders feel includes enough functionality and benefits that we can roll out the application into production.

Each item in the feature list is also assigned an Effort Required rating from 1 (easy) to 5 (hard).  This is just a rough estimate done by me (the development manager) that gives everybody an idea of the work required to implement each feature relative to the other features.  If I find myself giving a rating of 5 (hard) I will usually attempt to break the feature up into 2 or more smaller features that can be tackled separately.  If I feel a feature is a 1 (easy) I will see if I can group it together with another related feature.

Along with each feature we also maintain a % Complete which is updated by the developer(s) working on that feature.  We define specific percentages to represent key points (milestones) in that features lifecycle.

0-49% is under development
50% is ready for review by the feature owner(s)
60% means it has been reviewed
61-79% means it is undergoing revisions as a result of the review
80% is ready for demo to the larger group (at our weekly meeting)
90% means it has been demo'd
91-99% is undergoing final revisions as a result of the demo
100% is completed

Now that we have the effort required rating for each feature (I also call these "Work Points") and the % complete, we can do a number of useful calculations.  We can multiply out the % complete by the Work Points for each feature and sum it up to get the total work points completed.  If we compare this to the total work points required we can come up with a % complete for the whole project.  We can also track the # of work points completed each week/month to determine the velocity.  Using this we can calculate the estimated time required to complete all the remaining work points.  I produce a status report every week that includes all these calculations.  Here is a sample of what it looks like:

The beauty of this report is it is extremely easy to generate (when I get some spare time I may write some code that automates the generation of this report by reading from sharepoint directly).  It also provides very useful information, to me, the project stakeholders and upper management.  The % Complete number gives a quick update on the progress being made on the project.  And the Estimated Go Live Date is a useful piece of information to compare against any previously created timelines or deadlines.  Since it's based off of real measurements of progress it makes it much more useful than somebodies (usually mine) wild estimate of when we'll be done.

Do any of you guys do something similar?  Let me know what you think in the comments.

posted on Sunday, December 31, 2006 3:18 AM

Feedback

# re: Project Management Process + Tools 1/15/2007 7:27 AM Robert May
Very interesting. What do you do if your go live date doesn't track with the date the stakeholders are "requiring?" I'm assuming you drop features? How do the stakeholders react to this? How have you educated them to this process?

Good read.

# re: Project Management Process + Tools 1/15/2007 9:02 PM Dylan
The Estimated Go Live date is constantly fluctuating as the situation changes. And tracking this value against the prior commitments is definately something that I (and others) are checking on a regular basis. If they come out of whack there are a few options we can choose (well really just 2). Basically either cut back on features, or increase resources. Alot of times the velocity will drop in one week, consequently causing the estimated completion date to fall behind. But depending on the situation sometimes this drop in velocity is explainable. For example, we recently switched over our corporate network to a new domain. My development team was called upon to help fight the fires (was a definate lack of planning from our network group). For the last 2 weeks little to no development work has occurred. As a result our estimated completion date has been pushed out well into the future. Since I can explain the drop in velocity, I'm not too concerened. I realize that in the coming weeks it should pick back up and we'll get back on track. If 2 weeks down the road the estimated go live date is still looking bad, then I will be more concerned.

In my environment though this usually isn't a major concern with the stakeholders. Since we're in-house developers, our stakeholders/users are more concerned with getting a stable fully-featured product than they are about timelines. It is usually upper management which is more concerned with the timelines. And like I said, we have the basic paths to deal with that, cut back on scope, or increase resources.

# re: Project Management Process + Tools 1/15/2007 11:01 PM Dylan
To add to my previous comment. The real benefit here to me actually having an estimated go live date to compare with our commitment.

Previously our estimated date would be based on a timeline, that is almost always out of date. Anytime I wanted to come up with a new estimate I had to spend time recreating a new timeline with the current state of the project. This may be a sign that we weren't disciplined enough to constantly update and track progress against our original timelines. But I feel that having this measure of velocity is much much easier to generate and more valuable information.

And since I wrote this post I spent a couple hours and threw together a simple program that reads directly from the Sharepoint database and generates this status document automatically; it literally takes me about 5 seconds to generate this.

Post A Comment
Title:
Name:
Email:
Comment:
Verification: