22 November 2009

Planning versus Experience

Here is a thought; Suppose the more experience you have with a particular knowledge domain, the less you need to plan the work?



I picked this planning versus experience concept up from a Jim Coplien piece on InfoQ a few months ago. The idea was basically this; If you have 20 years experience doing roughly the same work you should acknowledge that the 20 years means you have a lot of your plan pre thought through before you even turn up.

In the piece I was watching (it was a video) the argument was being used to discuss the degreeof planning for "Agile" projects.  How much is too much planning and how much is not enough? The answer lies in the experience of the team.
  • Have they worked in this domain before?
  • Have they worked together before?
  • How much and how well?
  • etc
So if I follow this logic I start to see that highly experienced teams and people need to spend less time on planning.  In fact, if the are investing months into pre-project planning they are perhaps wasting money.

At the inexperienced end of the spectrum the idea is almost reversed, but not quite.  Yes you do need to spend more time planning, but not too much because, frankly, your inexperience means you'll make heaps of planning errors.  Instead go for short milestones and correct along the way.  Of course an inexperienced team does need to plan, and one of the things it should plan to do is get mentoring or coaching from someone with the appropriate knowledge and skills.

And in the middle of the experience spectrum the trap is analysis paralysis where the knowledge planning brings keeps teasing you to go just a little bit further.  In this space you'd be better off starting with a clear focus on the next deliverable and reviewing the plan as you go.

Thoughts?

9 comments:

  1. Craig,

    Interesting concept. I'd say here in A&D the inverse is true. The more experience we have the more we plan.

    Why because with more experience, we're scared not to plan in depth, even if its a similar program.

    Version 5 of a helicopter display system is now in it 7the year of production, the planning for version 5 was equivalent if not more detailed than version 1. We now know more where the problems are for version 1 and more about what went wrong in the planning processes, more about the statistical nature of the work processes

    ReplyDelete
  2. Craig, Interesting model. i understand your logic behind it, but i dont actually understand how to interpert the model. Could you assist?

    ReplyDelete
  3. @Glen

    I agree wholeheartedly with a capabilties based approach to planning and requirements management.


    And I appreciate that large system of systems projects are a different category to typical enterprise application or product development projects, even complex ones.

    I dobelieve that most enterprise projects are slight variations on ones that have one before.

    I think a pattern approach to these projects goes a long way. Thus applying pre-used patterns saves a lot of time.

    Th main variables are number/complexity of stakeholders and amount of system capability you want to squeeze into the IT parts.

    So, manage your stakeholders & requirements closely (by getting close support from your sponsor) and your risks go down and probability of on target performance go up.

    ReplyDelete
  4. @Nick,

    What parts are not clear? Basically it's left-to-right and low-to-high represent low-to-high 'capability' in those dimensions.

    I don't think this is a practical model; more a discussion piece.

    ReplyDelete
  5. A picture is worth a thousand words.

    I like your model, seems to accuratly represent the way you'd expect things to work.

    ReplyDelete
  6. This is interesting, but from my experience I don't think it's useful for a few reasons.

    Let me tell you why.

    Controlling for all other variables, I think the real causal relationship here is that more experienced teams means more distribution of the planning activities, and less friction with communication and collaboration.

    For instance, if you are working type of project you've never done before, you might bring in a consultant who DOES have that experience. They do most of the planning in that case. When you and the team gain more experience, you don't need to rely on a few individuals for planning, everyone can contribute and plan for their own deliverables.

    The other factor that's missing is complexity, which has already been alluded to. The more complex in terms of agencies/organizations involved and integration that needs to happen, the more RISK you have of things like key people leaving, communication failure, etc. Planning and documentation mitigates this risk and means that you can get a new contractor in if something bad happens and they don't have to start from scratch.

    Third, take it to an extreme operational analogy where the same thing is done day in and day out. This doesn't mean you throw away all your process documentation, when you experience turnover and other changes you want it there for reference.

    Perhaps with routine projects you've got a lot of the planning work already done for you because you can pull from previous work, but that doesn't negate the need for it one iota. Your planning will be better, quicker, and easier with experience; but the amount of planning needed depends on the project itself, not the team doing the work.

    Overconfidence and the "curse of knowledge" can easily make you blind to risks and things you should plan for.

    Josh Nankivel
    pmStudent.com

    ReplyDelete
  7. @Josh - I think we are using ifferent definitions of planning.

    Check this nd let me know your thoughts.

    ReplyDelete
  8. @Craig, based on that post's breakout of planning vs practice it seems we have been using different definitions of planning.

    It seems like you still have your practices documented, which is good.

    ReplyDelete

Search This Blog