• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "Project Management vs. Programme Management vs. Program Management"

Collapse

  • scooby
    replied
    Originally posted by Hot Mess View Post
    Project / Programme Management is not difficult, yet there's an army of chancers who'd like to make it so. Please just get me someone who understands what is being delivered, why it is being delivered, what isn't being delivered who gets on with the project team and communicates.

    Don't care about your methodologies, and nor does the business
    Completely agree, but methodologies put in place the governance and reviews that people dont like to do, i.e. is it working, should we canx it? If you do that without following a methodology then fine... Oh, and have the balls to canx it, not just think about it!

    Dont instantly blame the PM (although I've met several who are tulip), I've met more client management who dont get it or understand it!. Two sides to every story.

    Oh, one other thing, like methodologies or not, you will struggle to win public sector work without them, as they all follow the OGC... Doesnt make it right i know, but it's true.

    Common sense is the real key, listen to and question what the SME's are saying, plan for the worst. That is something no methodology teaches.

    Leave a comment:


  • scooby
    replied
    Originally posted by oracleslave View Post
    If there is no benefit to a project, why do it at all?
    because the output maybe an enabler. it's not all about benefits. you can have outputs that are not benefits.

    Leave a comment:


  • Hot Mess
    replied
    Originally posted by oracleslave View Post
    If there is no benefit to a project, why do it at all?
    +100

    I have lost count of the number of so called 'expert' project / programme managers I've come across, who fail to grasp this concept.

    Very keen on regurgitating their own opinions on methodology and 'best practice', at the expense of establishing what the business wants.

    Project / Programme Management is not difficult, yet there's an army of chancers who'd like to make it so. Please just get me someone who understands what is being delivered, why it is being delivered, what isn't being delivered who gets on with the project team and communicates.

    Don't care about your methodologies, and nor does the business

    Leave a comment:


  • oracleslave
    replied
    Originally posted by scooby View Post

    Programmes are strategic and have blueprints and benefit realisation plans etc. Projects have product descriptions and are generally operational or tactical.
    If there is no benefit to a project, why do it at all?

    Leave a comment:


  • scooby
    replied
    a Programme is a collection of projects that collectively deliver defined benefits (i.e. its about the greater good!). Projects deliver products / collection of workpackages. Portfolios are a collection of projects with similar products / deliverables. Programmes can contain portfolios which contain projects, or a programme can contain just projects.

    Programmes are strategic and have blueprints and benefit realisation plans etc. Projects have product descriptions and are generally operational or tactical.

    Leave a comment:


  • cojak
    replied
    Originally posted by malvolio View Post
    And, subject to my earlier caveat, that goes a long way to explaining my distrust of people standing around a table deciding what to do today. You should already know.
    Actually it's not really a case of deciding what to do as opposed to stating what what you did yesterday, what you're doing today and any blockers. The rest of the team can offer help/ask questions and everyone knows what the other team members are working on (something of a novel idea in my experience).

    It's more a progress and communication tool, slackers don't have too many places to hide in an Agile team.

    Leave a comment:


  • malvolio
    replied
    Originally posted by oracleslave View Post
    What's a work package then?
    A piece of work for an individual or a defined team. It may be a project (or perhaps a sub-project) in its own right or a single deliverable/milestone within another project. Or anything else. Who cares.

    Now do you see what I have little patience with the minute application of Prince2? In the real world you have deliverables and time-based dependencies expressed as a series of milestones. How you deliver either one and what you call it is actually irrelevant, as long as you meet the requirements of my overall plan. All else is fluff.

    And, subject to my earlier caveat, that goes a long way to explaining my distrust of people standing around a table deciding what to do today. You should already know.

    Leave a comment:


  • oracleslave
    replied
    Originally posted by malvolio View Post
    Call me a neo-Luddite, but a set of related tasks with a single end deliverable is a Project
    What's a work package then?

    Leave a comment:


  • redgiant
    replied
    Originally posted by SimonMac View Post
    I'm neither a PrM or a PjM so I don't care
    Opps .. I meant Peter

    Leave a comment:


  • cojak
    replied
    Originally posted by NotAllThere View Post
    I've read that twice and while I understand most of the individual words, I still can't make head nor tail of it. It's probably something to do with a paradigm of exploiting synergies within the team dynamic.
    I think that's what happens if you're around this kind of thing for too long.

    Just wait until we get onto Adaptive Case Management...

    Leave a comment:


  • NotAllThere
    replied
    Originally posted by cojak View Post
    I'm an Agile BA bringing in DSDM structure to a previously SCRUM project. I'm not having a huge problem bringing project governance/discipline in as the client likes the Agile approach but misses the Prince2-type structure that helps with things like finance and change control. It's all about a light touch and steering the team rather than anything else - I'm sure we'll end up with complimentary bits of both Agile approaches.
    I've read that twice and while I understand most of the individual words, I still can't make head nor tail of it. It's probably something to do with a paradigm of exploiting synergies within the team dynamic.

    Leave a comment:


  • cojak
    replied
    Originally posted by Peter Loew View Post
    Hi All,

    My current client is an interesting one. They're more or less starting their business from scratch, and the business is centered around developing a web-based product that they will ultimately host and 'sell' using a SaaS business model.

    I came in as a PM and have started putting the usual things in place; a PM process (PRINCE2 based but allowing for an Agile delivery model), PID, the usual control documents etc.).

    We've now had a new guy come onboard as an Non Exec Director, who has introduced some interesting techniques (what I would call techniques) for managing the project. He comes from a development background and is quite senior in another major web-based company that everyone's heard of, and has introduced the Kanban board for managing the entire project by doing standups every morning with the management team. Though I'm used to this in a development team context, I have to say that so far this is actually a good technique for keeping track of high level work that us management people are doing.

    However, he has now started to refer to the project as the 'Program' (deliberate spelling), and activities on the board as 'Projects'. Although I run the standups and I am the PM, this terminology and the associated concepts of Programme Management that I and other here are used to is becoming confused and inconsistent.

    We don't really have a Programme (in the UK/PRINCE2 sense), we actually have a Project with multiple work streams (in the PRINCE2 sense). He also calls these work streams, 'swim lanes'.

    To me this all sounds like a very American/'Agile development' way of doing things and I have a looming concern that the entire project is being too heavily influenced by Agile development/technical concepts (which isn't always a bad thing but tends to steer attention away from formal project governance).

    We're now having a debate on what terminology to use: Project, Program, Programme, etc.

    So I don't really have a question, but rather I'm asking for some advice and asking if any of you guys have been through this before and ultimately know what will be best for the project?

    It's an interesting position to be in, and I feel the choices we make now will affect how well the project is run later, hence the reason for this post.

    Thanks and look fwd to an interesting discussion!

    P
    I'm an Agile BA bringing in DSDM structure to a previously SCRUM project. I'm not having a huge problem bringing project governance/discipline in as the client likes the Agile approach but misses the Prince2-type structure that helps with things like finance and change control. It's all about a light touch and steering the team rather than anything else - I'm sure we'll end up with complimentary bits of both Agile approaches.

    Leave a comment:


  • SimonMac
    replied
    Originally posted by redgiant View Post
    Simon - You probably thought of this as well but as you're working with a new business I think it would be a good idea to propose the standard program and project governance for the client and get it approved and in place. That way everyone knows where they stand and with you putting it together you will get people working they way you want them to (with some compromises!) and some extra brownie points with the client.
    I'm neither a PrM or a PjM so I don't care

    Leave a comment:


  • malvolio
    replied
    Call me a neo-Luddite, but a set of related tasks with a single end deliverable is a Project and a Programme is a set of related Projects (and a set of related Programmes is a business ).

    But then I can't be doing with all this lazy Agile nonsense anyway, outside two workstreams; a dynamic client-led development environment where you need to react to spec changes quickly, or a testing project where unexpected things are likely to come up. And both should be within an overall project envelope even then.

    As for spelling - we speak English over here.

    Leave a comment:


  • redgiant
    replied
    Originally posted by Notascooby View Post
    I think a lot of places struggle with programmes and projects - the worst place to be IMHO is having lots of projects that affect the same resources and applications with no over-arching programme.

    This leads to dependancie not being logged or managed, projects fighting over priorities and key resources (both people and environments) without a steering group to manage these and a lack of give and take to meet the common good (too much - "not part of my scope").

    A proper programme will have the key stakeholders involved, have a technical and business design authority to ensure there are no conflicts between projects in terms of scope, design and implementation.

    Rarely happens properly though.
    Happens all too frequently in my experience. One recent example was rolling out an upgrade for SharePoint but on a per department basis as individual projects without a program structure in place ... what a nightmare/clustertulip!

    Peter - You probably thought of this as well but as you're working with a new business I think it would be a good idea to propose the standard program and project governance for the client and get it approved and in place. That way everyone knows where they stand and with you putting it together you will get people working they way you want them to (with some compromises!) and some extra brownie points with the client.
    Last edited by redgiant; 24 April 2012, 11:19. Reason: Wrong poster :)

    Leave a comment:

Working...
X