Promote My Site

Stackranking is a valuable tool, simple to use, and it helps you concentrate on the very specific parts of a project. I do it because it helps me decide what criteria use to identify what to concentrate on. I like to stackrank pieces of my project by importance, cost, and risk. And I want a name on every piece so, in my head, I know who should know the answers.

You can also group like items together (many people do not do this) and then stackrank.

Things to look out for:

1> Same guy is at the top of several stack ranks. Eek.
2> Same project piece is at the top too. Double-eek.
3> Same guy is at the bottom of all stack ranks. Hmmm.

The first two are obvious - all your eggs in one basket. The third is interesting. You could have a guy who works on low risk, low importance, low cost pieces of your puzzle. Maybe that’s on purpose. Or maybe he’s coasting. Or maybe you’re under-utilizing someone. In any case, I prefer to have these things be more intellectual than accidental.

You could also have someone who is working on a high importance, high-risk, and low cost component. That might not be good - did you give it to the right player? Are you putting enough resources into it - is it low cost because you have a top player working on it instead of a team of three? Or are you being cheap and scary? Again, better to think it through.

This has to be a team exercise. How should I know what is risky? As my team likes to remind me, I left tech when PHP was the big new thing. (Someday they’ll hand me some Metameusil and a cane, swear to go.) I usually know what’s expensive, because I’m cheap about some stuff. Sometimes there is, er, lively discussion on what’s important. Never get between a design-centric guy and a code-reuse guy, swear to gosh.

Once we work through all that and discuss any tradeoffs and identify any issues, we usually group the pieces together into logical units. We use GUI, Database, Infrastructure, Back Office, Marketing, and Sales. Once again, we want a name on every piece - the go to person for know WTF is going on with that piece. We tend to be pretty heavily matrix’d so there is overlap on the ‘do’ side, but there is usually one knowledge leader on each piece.

Then we stack rank again (insert brisk and loud discussion here) by risk, cost, and importance and talk through the issues.

Usually what I’m looking for is to identify areas where we’re under investing, or where we’re starting go off the rails from a development/deployment/sales timeline. As we’ve said, earlier is better in these things.

The output may be some updated task lists, it may be that we need to replan, it may just be that we shift a few resources around. No matter what, I have never seen a two or three hour session fail to pay itself back.