Two project teams for the same “project!”

An article in The Times (March 1, 2010) caught my eye:

“Companies issuing shares to make an acquisition, should hire a second team of investment bankers to make the case against doing the deal, according to Warren Buffett”

This got me thinking. Imagine a team set up to argue against a project as well as team to argue for developing a project! The teams could focus on a number of important areas and some of these could include:

• checking out whether the risks are too great or acceptable
• developing a business case for or against the project
• identifying whether there any project benefits – what they are and whether they are achievable
• developing a plan identifying resources required and how this will impact on other projects and business as usual
• identifying whether you have sufficient resources of the right calibre
• checking there is a link back to the company strategy

An interesting idea; one to look at in further detail. 

Share
This entry was posted in risk management and tagged , , , . Bookmark the permalink.

3 Responses to Two project teams for the same “project!”

  1. This is why in US Federal Procurement, the Program Planning and Controls staff is separate from the technical performance staff.

    Engineers (software or hardware) are poor sources of measures of progress.

    As well this is why the Performance Measurement Baseline – a time-phased budget plan for accomplishing work, against which contract performance is measured. It includes the budgets assigned to scheduled control accounts and the applicable indirect budgets. For future effort, not planned to the control account level, the PMB also includes budgets assigned to higher level Contractor Work Breakdown Structure (CWBS) elements, and to undistributed budgets. It does not include management reserve – is mandated.

    The notion of planning the work and working the plan is the basis of any credible project management method. This can scale up or down depending on the complexity of the project.

    But in the absence of a “planned” performance baseline, there is no mechanism to hold those performing the work to be accounting for their effort. Work expands to fill the time, spending expands to consume the budget, and the resulting products may or may not meet the needs of the stakeholders.

    Only (IMHO) when you have a Program Control group in parallel with the development group can any credible assessment of progress to plan be available.

  2. Ron says:

    Thanks Glen for the posts, I appreciate the time taken. I did a double take with the words:

    “Engineers (software or hardware) are poor sources of measures of progress.”

    Not too sure they would agree however I think it interesting to note your initial premise of the split in responsibilities.

    Many thanks as ever Glen!

    Ron Rosenhead

Leave a Reply

Your email address will not be published. Required fields are marked *