When I worked as an IT project portfolio manager for The Washington Redskins I was fortunate to work for a great IT Director and probably one of the most capable executives I've ever seen up close. He had been the CFO and was now the COO and just one of his dozens of duties was to manage all stadium construction. When Mike (the executive) inherited the IT department he treated our projects just like he'd treat a stadium renovation: you don't put a shovel in the ground until you've got a complete set of blueprints that you and everyone else has sweated over and reworked until all the key stakeholders are satisfied. His approach was to deal with the architect first, then bring in the construction crew.
Now we did some very cool stuff with IT while I was there, things that were the first of their kind. As far as I could tell from a distance, Dan Snyder was not that involved in the day-to-day operations of the franchise--he had really capable executives for most of that. But man could he connect the dots. He really could look out on the larger business landscape and see patterns and opportunities and potential connections where others couldn't. Hence the innovative uses of IT.
If you are interested in project management approaches and methodologies like I am you're also aware of the ongoing discussion we have amongst ourselves about what model we should align ourselves with. Should we follow the construction model mentioned above? Or maybe we're more like product design where you know you need to bring something of value to the marketplace within several design constraints, but at the outset you're not sure what that will look like and you go through a process of discovery along the way. I've always thought one of the premier student's of project metaphors is Alistair Cockburn, and I like his notion of projects as cooperative games.
In my opinion, this is a fun academic discussion that I enjoy as much as anyone (just ask the patient folks that work with me), but the real answer on which approach is "right" is, "it depends."
Projects are not operations. Projects have a beginning and an end. Projects are like films (there I go with metaphors again, sheesh). You might be an accomplished director and have several films under your belt, but this film with this exact crew and talent and market dynamics and script have never been done before. So there are principles you can follow that apply from film to film, but you also need to adapt to the unique dynamics of the moment and pull from your toolkit what you think the situation needs.
There are times when it makes sense to spend six months writing and refining a requirements document. There are times when it makes sense to just start moving and adapt as you go. My next blog post will probably go into these scenarios a bit more, but the point is that we often get way too rigid and ego invested and almost religious about "the one true way" of managing projects when the reality is that there's merit in all approaches. You can adopt one way of doing things and become an accomplished XYZ technician and that's fine. But you've just boxed yourself in, professionally. Or you can take the harder road and learn waterfall, learn scrum, learn critical chain, learn getting real, etc. and be a technician in several approaches and an artist--pulling in a practice here and approach there from multiple perspectives and doing what you see the situation calls for.
What we should be religious about is scope, schedule, and budget.
No comments:
Post a Comment