Abstractions In Project Management
Abstractions In Project ManagementI've recently been involved in writing a project proposal. Due to the nature of the client's organization, a bit of BigDesignUpFront is required in order to get the proposal through their acceptance process. The proposal has to include functional requirements, architectural diagrams, task breakdowns, cost estimates, schedules, deliverables, acceptance tests, etc. (You XP advocates don't need to tell me about the dangers of this approach. I know.)
One particular aspect of the proposal was a problem. There were a few distinct ways to proceed, with widely varying costs, benefits, and risks. It was difficult to put together the rest of the proposal without some decisions being made about which approach would be used, but nobody was willing to make a decision about it.
So, I did what typical programmers do when confronted with something complicated: I "refactored" the proposal into two proposals. A new proposal for a separate project took care of the problematic stuff and then the original proposal was changed to assume that the other project was done and so it listed all the comparatively easy stuff.
Subsequent reviews and meetings regarding these proposals with the client have convinced me that this was the wrong thing to do. Splitting the hard project into two easier projects has left the client convinced that the whole thing is going to be easy, despite my repeated premonitions of doom for us all. One good result is that splitting the hard issues into a separate document has finally made them willing to make some hard decisions, but now that those decisions are made, the hard part now seems easy. There is just something about breaking a big task into lots of easy tasks that makes the whole thing seem easier than it really will be.
We know that AllAbstractionsLie, even though abstractions are often useful. I have concluded that abstractions are especially dangerous when applied to things, like money and time, that are not as adaptable and controllable as software. It strikes me that this may be one of the reasons that many DeveloperTurnedManagers fail. Developers are accustomed to being able to turn hard problems into simple problems, but most management problems cannot be turned into simple problems without losing important information.
I'd be interested to know what project managers think about this. Do you make a lot of simplifying assumptions or intentionally ignore things in order to make your work doable? Or is it more important to constantly keep track of all the details and consciously fight off any urges to think of things as simple? When you delegate tasks to others, is that a means of simplifying your own work (in the complexity sense, not the working-hard sense)?
-- KrisJohnson
Where is the hard part of the project now? You say Splitting the hard project into two easier projects. If that's true, then you do now have an easier overall project. If it's not, you've left something out, and the two easier projects don't accomplish all the one hard one would have done. -- PaulHudson
I now have two projects which are each about half as hard as the original project. I don't think that is a real improvement, especially considering that there is some additional overhead associated with having two projects instead of one. We now have two approval processes to go through, two design documents to create and review, two acceptance tests, two sets of documentation, two operator training sessions, etc., and may even end up with two project managers and two development teams. The client now thinks of the two projects as being independent, ignoring the interdependencies.
I'm not too worried about this; I am pretty sure I can eventually explain things in a way that the client understands. But I think the project split was a tactical mistake. It was something I did to make development of the proposal easier, not something I did to make the actual management of the project easier.
I'm not looking for solutions for my particular problem. I am interested in principles used by people who know what they are doing. All managers use abstractions. For example, they will use measurements like number of lines of code, number of tests passed, or percent-complete as an abstraction of "progress". They use high-level task descriptions like "Write build procedure" as an abstraction for all the little sub-tasks that make up that task. They will delegate a task to "Frank's team", without thinking about which individual members of that team are actually doing the task. These abstractions are necessary for busy managers to make some sense of it all, but how does one make sure that such abstractions are not too far away from reality?
-- KrisJohnson
I'm not looking for solutions for my particular problem. OK, I can see that. My point was more that you'd deduced that the abstractions you had used had caused problems - from your description, I wasn't sure why they had, and if in fact the problems weren't inevitable, it might mean your conclusion abstractions are especially dangerous when applied to things, like money and time, that are not as adaptable and controllable as software. isn't necessarily true.
The DivideAndConquer (and then make the subparts someone else's problem) approach is certainly one I use in project management. Ultimately, at some level it's a necessity, unless the project manager is doing all the work as well. -- PaulHudson
I'm not sure what you are looking for, but here are a couple of principles. One, in absence of a change, do not revisit old decisions, accept them and move on. Two, in light of principle one, make no decisions lightly; understand what you will be getting yourself into. -- WayneMack
On the other hand, don't make decisions that you can't make or don't need to make yet. I've seen a lot of projects get bogged down with endless debate about which way to jump on a decision when the better answer would be do some other work, and make the decision when we have the information. This is the project management version of YAGNI. -- PaulHudson
Kris, you believe that one of the subprojects is heavily dependent on the other. What is it that allows the client to believe that they're independent? -- francis
I think it's just because they are now two different projects, described in two different documents, everyone is treating them as independent. There seems to be an underlying assumption that anything called a "project" is self-contained.
I can re-describe my problem like this: we had one project, viewed by all as being unpredictable and unestimatable. What I did was break it up into two projects: one that is easily estimatable based upon existing knowledge, and another that is estimatable based upon a set of assumptions about the most likely outcome of the first project. So, the second project's estimates are really based upon nothing but crystal-ball-gazing and hope. However, because there are documented estimates, the customer is proceeding to fund and schedule both projects as estimated. Whenever I try to remind them that the second project's estimates are contingent upon the first, they just respond that they're going to assume that the first one goes as planned.
To get back to the "abstraction" idea, I think in the managers' heads, these are just two more projects among many. To them, a project is an isolated activity with a financial cost, a schedule, and a goal that can be defined in five words or fewer ("integrate our systems"). The risk associated with a project is based upon evaluation of the people doing the work, not on the nature of the project. Dependencies between projects only affects scheduling order; risk of one project's "failure" affecting cost/schedule/goals of others seems to not be part of their mental models. There is a simplifying assumption that everything will go mostly according to plan. (Of course, my simplifying assumption that lots of things will go wrong and all these managers are ignoring it is an abstraction as well.)
So, rather than performing a detailed analysis of the projects, I think the managers' thought processes are as simple as this:
Ah, that made the problem clearer to me. Sooo..., as a project manager, you document the assumptions you've made in the project proposal for the second one, and have as a clearly identified risk that the assumptions may turn out not to be true. You get sign off on the assumptions and risks.
You have improved things, in that the success of the second project *has* some clear assumptions, and that (presumably) there's a milestone (or several) at which it will be clear if the assumptions have failed to be true. If the success of the overall project relies on the things you've determined, then you will know if it runs into trouble and be able to terminate it (or start the risk/crisis management actions) before too much time and effort has been wasted.
Our project tackles a very hard problem so we've also broken it down into a number of subprojects. So the situation is like yours in some respects. Even to the extent that go-nogo decisions on the subprojects put them at individual risk. We put together a simple communication tool we call the technology roadmap that shows how the subprojects build on their predecessors to create a successively more capable and robust technology. We show the roadmap every time we have a discussion with our customer involving more than one of the subprojects. Now we hear the customer asking "how does X fit in with the roadmap?" from time to time, so it seems to be working.One advantage of the roadmap is that by showing dependencies it highlights the risk of not doing a subproject (or of a subproject failing) - DaveVanBuren
EditText of this page
(last edited January 9, 2012)
or FindPage with title or text search