Well, maybe not technology planning itself - as far as I'm aware, I've never participated in an actual technology plan (although, interestingly, I've experienced everything listed in the What Went Wrong article anyway). This unit has proven to be a bugbear, though, in that I've been unable to effectively organize my thoughts and get the writing done.
Which is just what I'd expect to happen if I were drafted into writing a technology plan (see how I did that). I am very much one of this world's accidental technologists: the child of two IBM lifers who wanted to be an artist. I prefer things to stay organic and intuitive (translation: I don't like to put in the advance work, it's boring). I wonder how many tech plans have been written by people like me?
So it may not be surprising that one of my favorite pieces of wisdom from this unit's readings is to keep things open; don't write a plan that's so specific it boxes you in and leaves you with no place to go when things go wrong or just go different. Another, from Chabrow, is to fail fast. As long-serving state employee (no time off for good behavior), I've seen a lot of projects outlive their usefulness before they've even gotten off the ground.
If a technology planning process ever does come my way, I think I'll have a more thoughtful contribution to make. It will help that I'm making a list of the causes for project failure that come up multiple times in both the readings and on our discussion board; these are the real bugbears - poor needs assessment, scope creep, failure to bring the crew on board before setting sail.
This late, late post has been back-dated to keep things in order.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment