You’re a project manager or a developer or a support engineer. Doesn’t really matter. You use some project management methodology. Agile, iterative, formal, whatever. Doesn’t really matter. When a serious issue appears on the horizon, your methodology tells you more-less what the person in your position should do. Reject any external change until current sprint is finished, choose the development cycle which the feature will be added in, start formal change request process or whatever.
That’s the default path. You can follow the path and probably no one would blame you. Unfortunately there’s a trap in that approach. There’s no procedure which can tell you how to act well in every possible situation. All you can find is what to do in typical situations. Unpredictable things happen much more often than once in a lifetime. Actually you can predict that unpredictable will happen and it will happen quite often. In these situations default answer shouldn’t be default any more.
We had a subcontractor who failed to fulfill their commitments within the project. They didn’t really care about potential consequences because they didn’t intend to continue cooperation in the long run, as it appeared later. On the other hand our deal with the customer was crucial for us.
The default answer was: squeeze the subcontractor as hard as possible, while trying to calm the client down. We would probably take another 3 or 4 months of painful cooperation and finish the project anyway, as it already was on quite advanced stage. We did something else. We overtook the part of the unfinished development work from the subcontractor (which required ad-hoc team reorganization) and completed the project in less than a month. If we had to justify our decision we’d be talking about vague criteria like belief our team would make it or feeling it was a right choice. Try to find them as decision-making factors in any project management methodology.
Another example. After a couple of months of joint development with one of our clients we heard several um… let’s call them advices. The client expected extremely flexible approach up to possible changes requirements on any stage of the project with the instant reaction (implementation) on our side.
The default answer was: we follow this or that methodology and it tells you we have to formally manage changes. That mean you have to wait until we’ll be finished with current iteration/sprint/whatever until we’ll do that. Or better: hello, there’s not a word about that in analysis. Can’t do, sorry. On the other hand we used common sense which told us the joint development program is very valuable for us and as far as we’d set up our thinking on paths expected by the client it can go quite smoothly and both sides could be happy. So without much thinking we went for that so-called flexi project management (which has more to do with “flexi” than with “project management”). After all the both sides are happy I guess.
When you switch off common sense and constant thinking how issues can be solved other way than default one you fall into the trap. Standard answers are good for standard questions which are surely far more than 90% of project management work. But for the remaining few percents you need to act different. If you always look for an answer in procedures you got caught. Sorry.
Yes, unconventional actions are much easier to implement in small organizations where everything is less formalized. It is of course possible (yet rare) in big companies too, although in that case it is usually a function of people accountability, which is a function of company culture.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
