So why do so many projects separate what should be integrated functions?
An obvious example; separating the ownership of scope from the schedule and budget. A project sponsor cares about schedule and budget and then delegates the articulation of requirements to managers and operators who are not directly aligned to the sponsor's goals.
Is this "Dis-integration?"
Subscribe to:
Post Comments (Atom)
Popular Posts
-
Due to popular demand I have aggregated some information on User Stories and created a simple template. If you feel this would be useful to... -
I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ... -
Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
-
You've heard many reasons why project fail. Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
-
The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
-
In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
-
This is a guest post by Jeff Hobbs. Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
-
In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n... -
I'm a massive Lord of the Rings fan. Every year, I spend part of my holiday vacation rewatching the 12 hours of the blu-ray extended edit... -
The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
This separation starts when the project fails establish several things:
ReplyDelete1. A RAM showing who is doing what?
2. The WBS
3. The Integrated Master Plan and Integrated Master Schedule. Even if it it done in a simple manner, there needs to be a "Plan" showing the strategy for how the project will proceed from left to right and how each deliverable is measured for increasing maturity.
4. The definition - in units of measure meaningful to all the participants - of what "done" looks like for each pre-planned level of maturity at the time this maturity is expected.
So with the RAM the "owners" are defined for all the outcomes of the projects. Failure to do this is usually the source of these types of problems. It sound simple and is rarely done in the commercial world. It's mandated in our defense world.
With the RAM, the Integrated Master Plan can be built. The Plan shows what accomplishments must tale place and the "exit criteria" for the work producing those accomplishments for each point in the project where maturity will be assessed.
In the agile paradigm, this can be a release point.
Only then is the work planned at the Work Package level.
The RAM is the touch point for all work. If its not in the RAM, the WBS or the Integrated Master Plan, why are you doing it?
This approach is independent of the people aspects. This is a point missed in most commercial and agile projects. The notion that people trump process is nonsense for non-trivial projects. People are critical. But without a process, the project has no framework for the people to work within and everyone gets quickly lost in their own version of what to do.