Projects – Measuring success and providing boundaries

Working in the software industry lends itself to a lot of project work. Projects are an interesting beast that seem to be somewhat misunderstood and all too easily fail. Over the past few weeks I have had several discussions regarding all sorts of “projects” and reasons why the forecast is glum on their outcome. These projects are varied as running a sports coaching clinic, change management and of course the software project.

From my experience with project work, some projects felt good and you always knew they would succeed and others either started shaky or had a honeymoon period that eventually declined into a shaky project. Just to be clear I’m not a PM and this article isn’t so much about how to overcome politics, project buy-in or using Project office. I’m just pointing out some very basic principals that anyone involved in the project should be able to pick up on and should be able to implement on any size project be it professional or getting your son to keep the garden “Clean and Green” (a Stephen Covey analogy).

First: Set the success criteria. For a project to keep the garden clean, the success criteria might be “Clean and Green”. This is fairly easy to measure. If the grass or plants die or go brown, its not green. If rubbish or leaves start building up then its not clean. Easy.

If you are on a software project you may have the project success criteria and also some standards to be measured on. For example the development team may require 95% unit test coverage and comments on public types and members [standards]. The project may require an Order approval Use-Case. The measurement of this use case being delivered should be outlined by the business requirements [success criteria].

Well that seems obvious so what?

Second: Do not mandate how to implement the project. Step one was to provide a way to measure success, step two is not telling the team how to do it. Provide the boundaries but don’t turn your team in to drones. First it puts too much weight on someone to create all the “How’s”, second it undermines the talent of your team. Generally it is useful to provide an example of some “How’s” and explain why they could be good for meeting the success criteria. We provide an MVP pattern that allows for testing on our WPF client screens. The developer can use that pattern or another pattern if they wish, as long as the “unit test” measurable is met.

Third: Regular Feedback. A project is fluid. It could have many factors that could change priorities or direction of the project. Like ship at sea, a project needs to be steered. We cant just point the ship in one direction and fix the rudder, we might get blown off course. With constant feedback things that we never would or could have been thought of in advance can be identified. Here are some examples of feedback that have sailed or sunk a project depending on when there were identified:

• An e-commerce app that works great in one industry (IT Distribution) but failed miserably in another (Bulk Food delivery). The basket scaled to ~30 items. Most usages in the IT industry would place small orders once a day. However restaurants and Hotels tended to restock everything at the start of the week and the 200-300 item basket would blow out to over 1MB in HTML. When the basket tried to refresh on every modification the system became unusable on the target client’s dial up modems.
• 4 signifcant digits is normally fine for most measurements, unless you are working with GIS data. This was caught early as saved a project from certain failure.
• Feature creep that came from a “User” that described a “Would have” as a “Must have”. This required an large change in the cost of the project. On further feedback with other users it was identified correctly as out of scope.

Regular feedback as one method of improving communication sure can help keep the project on track for success. Keeping everyone in contact with each other is also a good way of ensuring people feel like a valued part of the project.

Fourth : Features, Cost, Time: Pick two. Some projects I have been on a PM hands over some requirements and tells me this must be done by X date. Unless the PM is very experienced, lucky or has some good metrics on build times; this just wont work. One is the function of the other two.

• pick the features and cost and I can tell you the time it will take
• pick the features and time and I can tell you the cost
• pick the time and cost and I can tell you what features can be done

The fourth point become fairly specific to commercial projects but the first three points can be applied to most “projects”. For me the second point is hard to do. For many it feel natural to control the outcome by controlling the detail. I have to learn to trust my team and let go.