The complete collection of requirements that the project beneficiaries might have for an individual project team are not usually readily apparent at the time the project is being requested, envisioned, budgeted, staffed and initiated. And, yet, this same complete collection of requirements is what the initial estimates, plans, skills, and task plans will be measured against when the project is finally in its completion phase(s).
Experts in the art and science of requirements gathering and analysis have postulated that the most critical point in a project's life is during the early stages of each project when these requirements are being identified, quantified, correlated, and prioritized. Even in the more recent practices of AGILE / SCRUM methods, the component that is being focused on in these AGILE / SCRUM sessions (the 'requirement') must be clearly identified before the development efforts in the SCRUM is begun.
Another consideration that is part of the AGILE / SCRUM process is the identification of portions of the targeted capability or requirement that can be removed from the deliverable because of a lack of clarity and / or understanding between the users requesting these capabilities and the developers who are trying to build it. Comparmentalizing a requirement in a SCRUM, Iterative, or Waterfall development process is extremely important if the project team is to make a decision to eliminate a piece of the proposed solution during the performance of the project (AGILE, Iterative, Waterfall efforts are considered all to be projects).
It is especially important to know the up stream and down stream dependencies of the feature being considered for removal before making a final decision. The extent of the impact of removing a capability can be defined by knowing what is before and after the candidate capability.
... the next edit of this post will begin to expand on the techniques that can be used to improve the likelihood of gathering a complete set of requirements bgbg ..
Sunday, June 21, 2009
Tuesday, April 29, 2008
The Five "P's" of PMO
The definition of PMO, the acrnoym, has been difficult to pin down to date. There are many interpretations, both, in the service delivery community and the business operations organizations who express an interest in having one.
Since each organization is very different based on their Objectives and the people they hire, and the most pressing need at any one of these organizations can be decidely different from any of the others, the actual delivered PMO can be an extremely unique organization and set of procedures and metrics.
I believe that one of the most important things we can do, first, in any engagement is help the customer understand some of the differences between:
Since each organization is very different based on their Objectives and the people they hire, and the most pressing need at any one of these organizations can be decidely different from any of the others, the actual delivered PMO can be an extremely unique organization and set of procedures and metrics.
I believe that one of the most important things we can do, first, in any engagement is help the customer understand some of the differences between:
- Program Management
- Project Management
- Process Management
- Portfolio Management, and
- People Management
These are my "Five 'Ps" for a PMO and they help me to understand where the highest priority need is and how to focus our efforts on getting a valuable PMO in place early from which we can build additional capabilities (other "P's") when necessary.
bgbg
Third Time Pays for All!
How many of you have tried to start your own company and it didn't work the first time? This one is my 2nd attempt and so far it's working but I am sure I could use some fine tuning and pretty soon.
One thing I have noticed is that in my first attempt I had a partner who had significantly different skills than I did AND we seemed to mesh pretty nicely until it just went sour. I know I have skill gaps and I am being reminded, EVERY DAY, that I am a really BAD ACCOUNTANT!
On the other hand, I do pretty well at building and maintaining relationships with some people.
Have you ever thought of building a collaboration of small companies, each of whom would provide organizational services to the others in the group? I think they call this a 'consortium' and although I have heard of one or two of these, they have never impressed me as substantially beneficial. However, I have only been trying this on my own for less than two years now. These organizations could get to look better and better as time goes by.
bgbg
One thing I have noticed is that in my first attempt I had a partner who had significantly different skills than I did AND we seemed to mesh pretty nicely until it just went sour. I know I have skill gaps and I am being reminded, EVERY DAY, that I am a really BAD ACCOUNTANT!
On the other hand, I do pretty well at building and maintaining relationships with some people.
Have you ever thought of building a collaboration of small companies, each of whom would provide organizational services to the others in the group? I think they call this a 'consortium' and although I have heard of one or two of these, they have never impressed me as substantially beneficial. However, I have only been trying this on my own for less than two years now. These organizations could get to look better and better as time goes by.
bgbg
Subscribe to:
Posts (Atom)
