Be always at war with your vices, at peace with your neighbors, and let each new year find you a better man. ~Benjamin Franklin
Friday, December 31, 2010
It's New Year's Eve!
Wednesday, December 29, 2010
The Closer!
Michael Young has a posting on PMHut about closing the project. It's aggressively titled "A complete guide to closing projects"
Except I don't think it's complete, or complete enough
It's a good discussion as far as it goes, but here's what he says about archiving data:
Following delivery of the Post Implementation Review Report, the project database is archived. Building a repository of past projects serves as both a reference source and as a training tool for project managers. Project archives can be used when estimating projects and in developing metrics on probable productivity of future teams.
Now, that's necessary, but not sufficient. What you really have to do is update the enterprise estimating models, not just archive the project. Maintaining models is really the only way to improve estimating. If I say that a "hard" specification requires "X" hours with "Y" skills, the credibility of X and Y are on the line in proposals and in execution.
Too many organizations "build a repository of past projects" without putting the effort into mining the information in that repository to refine a model of how the organization really works.
And of course, the outliers have to be dealt with, either in the footnotes, or in the distribution of possible outcomes. After all, X and Y should be expected values if they are single numbers, and if not, then they should be ranges, better yet: percentile rankings. To wit: a hard specification requires X hours at the 95th percentile. Now we have something we can work with.
My advice: don't just close; be a Closer!
Bookmark this on Delicious
Except I don't think it's complete, or complete enough
It's a good discussion as far as it goes, but here's what he says about archiving data:
Following delivery of the Post Implementation Review Report, the project database is archived. Building a repository of past projects serves as both a reference source and as a training tool for project managers. Project archives can be used when estimating projects and in developing metrics on probable productivity of future teams.
Now, that's necessary, but not sufficient. What you really have to do is update the enterprise estimating models, not just archive the project. Maintaining models is really the only way to improve estimating. If I say that a "hard" specification requires "X" hours with "Y" skills, the credibility of X and Y are on the line in proposals and in execution.
Too many organizations "build a repository of past projects" without putting the effort into mining the information in that repository to refine a model of how the organization really works.
And of course, the outliers have to be dealt with, either in the footnotes, or in the distribution of possible outcomes. After all, X and Y should be expected values if they are single numbers, and if not, then they should be ranges, better yet: percentile rankings. To wit: a hard specification requires X hours at the 95th percentile. Now we have something we can work with.
My advice: don't just close; be a Closer!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Monday, December 27, 2010
Schedule heresy
Here's a little heresy on schedules, just before the holiday break:
I don't like, and don't recommend, MSProject and similar tools for managing a project!
Why?
Plan v Manage
There's too much administration and faux assumptions day-to-day managing dependencies for it to be an effective management tool, especially for smaller projects. There's always a mad scramble and a lot of time and effort taken up on evaluating ad-hoc task level interactions, most of which can be worked out by other means.
On the other hand, it's a great planning tool to get a project started, including a consideration for dependencies, resource conflicts, and other artifacts. As a planning tool, so long as dependencies are restricted to finish-to-start, and there are no fixed dates, it's a good tool to host Monte Carlo simulations. It's just that once a project is under way, milestone charts, gated criteria, and earned value spreadsheets are better tools on account of their efficiency, even on large projects.
Walk the talk
I finished an engagement a couple of years ago that went several years, consumed multiple hundreds of millions of dollars, involved hundreds of project staff, and had four blocks of deliveries over two years.
And, we never had a task-level project schedule.
What we had were swim lane milestones and major dependencies identified between swim lanes. Within the lanes, there were one or more teams and planned interteam dependencies, each team with their milestone schedules, and within teams, there were small working groups, also with milestone schedules.
We set up pipelines for sequential delivery, and gates to frame the pipelines. We managed the pipelines with Excel. [Look for more on pipelines in a future post]
We also did resource leveling with Excel.... that's a good thing! The algorithms in schedule tools can return some silly answers. I always marvel at Excel--it's truly amazing what you can do quantitatively with that tool!
We successfully delivered business value. The first block was late--and that was a value bummer--but the next three hit their milestones on time. We did not successfully earn the intended project EV package of cost-performance-schedule. It was an ERP project [Oracle business systems] for a multi-billion$ enterprise. Re EV: ERP says it all!
In any event: Plan with MSProject [or Primavera, or other similar], but manage with milestones, gates, and EV
Bookmark this on Delicious
I don't like, and don't recommend, MSProject and similar tools for managing a project!
Why?
Plan v Manage
There's too much administration and faux assumptions day-to-day managing dependencies for it to be an effective management tool, especially for smaller projects. There's always a mad scramble and a lot of time and effort taken up on evaluating ad-hoc task level interactions, most of which can be worked out by other means.
On the other hand, it's a great planning tool to get a project started, including a consideration for dependencies, resource conflicts, and other artifacts. As a planning tool, so long as dependencies are restricted to finish-to-start, and there are no fixed dates, it's a good tool to host Monte Carlo simulations. It's just that once a project is under way, milestone charts, gated criteria, and earned value spreadsheets are better tools on account of their efficiency, even on large projects.
Walk the talk
I finished an engagement a couple of years ago that went several years, consumed multiple hundreds of millions of dollars, involved hundreds of project staff, and had four blocks of deliveries over two years.
And, we never had a task-level project schedule.
What we had were swim lane milestones and major dependencies identified between swim lanes. Within the lanes, there were one or more teams and planned interteam dependencies, each team with their milestone schedules, and within teams, there were small working groups, also with milestone schedules.
We set up pipelines for sequential delivery, and gates to frame the pipelines. We managed the pipelines with Excel. [Look for more on pipelines in a future post]
We also did resource leveling with Excel.... that's a good thing! The algorithms in schedule tools can return some silly answers. I always marvel at Excel--it's truly amazing what you can do quantitatively with that tool!
We successfully delivered business value. The first block was late--and that was a value bummer--but the next three hit their milestones on time. We did not successfully earn the intended project EV package of cost-performance-schedule. It was an ERP project [Oracle business systems] for a multi-billion$ enterprise. Re EV: ERP says it all!
In any event: Plan with MSProject [or Primavera, or other similar], but manage with milestones, gates, and EV
Are you on LinkedIn? Share this article with your network by clicking on the link.
Saturday, December 25, 2010
Happy Holidays
From all the folks that make "Musings" possible:
Photo credit: http://dreamscansing.blogspot.com/2010_09_01_archive.html
Photo credit: http://dreamscansing.blogspot.com/2010_09_01_archive.html
Thursday, December 23, 2010
The Theory of the Mosaic
And so we have the "Theory of the Mosaic", which roughly told is given by this:
From many disparate and small bits, hiding in public and knowable to those who seek, comes a revelation of the larger idea and greater knowledge
This is much more than just seeing the forest in the presence of trees; this is finding the trees in the first place, and then placing them in context, in juxtaposition, and in relationship so that not only the forest, but all the attributes and nuances of the forest are revealed.
Project management?
You betcha!
The proposal project
Let's begin with the competition to win new business. Bidding competitively is a project in itself; it's only after you win that the execution project begins.
One of the tools used by practitioners of the Theory of the Mosaic is the "expert network". These are the relationships that extend in myriad directions and trade "bits" in the marketplace of knowledge [sometimes rumor or conjecture]. In competition, the network extends not only to the potential customer, but to the customer's customer, regulator, appropriator, and suppliers. It even extends to the direct competition. How many of us have sat down with our direct competitor for a chat about the 'opportunity'?
Assembling all this information [in many cases, just bits of data, not even information] into a narrative that can be then transformed--through the proposal process--into a WBS, cost, schedule, and performance promise for a winning offer is no small task and requires all the discipline and commitment to an objective that is the mark of successful project management.
Of course, one of the tenants of the Theory is that information is hiding in public. Expert networks to ferret out the public information is the secret to success. Usually, there is a bright line--that is, no peek at proprietary competitive information that is unethical or illegal is permitted--but often the line gets blurred, the rules change [sometimes in mid-stream], or international ambiguity [read: culture] mislevels the playing field.
Guardianship of such corruption is no small matter. Just refer to the infamous USAF refueling tanker competition for many "don't do this" examples.
The execution project
No project of any scale operates without interpersonal relationships, a dollop of politics, and the obscure actions of many people working on their part. Enter: "expert networks". The project manager for sure, work stream managers, and cost account managers all 'work their networks': up and out to the sponsors, and down and in to the worker-bees.
Assembling the mosaic
For those experienced in brainstorming, assembling a mosiac from an expert network is really no different.
First, the science:
Like items are grouped
Relationships are labeled
Sequencing is labeled
Small items are grouped under bigger items
Gaps are identified; gap filler plans are formulated
Narrative headlines are written
Then, the art:
Interpretations are made; the 'big picture' emerges from the 'pixels'
Importance and urgency are weighed
Actionable 'intelligence' is separated for execution plans
Finally: act on the intelligence!
Bookmark this on Delicious
From many disparate and small bits, hiding in public and knowable to those who seek, comes a revelation of the larger idea and greater knowledge
This is much more than just seeing the forest in the presence of trees; this is finding the trees in the first place, and then placing them in context, in juxtaposition, and in relationship so that not only the forest, but all the attributes and nuances of the forest are revealed.
Project management?
You betcha!
The proposal project
Let's begin with the competition to win new business. Bidding competitively is a project in itself; it's only after you win that the execution project begins.
One of the tools used by practitioners of the Theory of the Mosaic is the "expert network". These are the relationships that extend in myriad directions and trade "bits" in the marketplace of knowledge [sometimes rumor or conjecture]. In competition, the network extends not only to the potential customer, but to the customer's customer, regulator, appropriator, and suppliers. It even extends to the direct competition. How many of us have sat down with our direct competitor for a chat about the 'opportunity'?
Assembling all this information [in many cases, just bits of data, not even information] into a narrative that can be then transformed--through the proposal process--into a WBS, cost, schedule, and performance promise for a winning offer is no small task and requires all the discipline and commitment to an objective that is the mark of successful project management.
Of course, one of the tenants of the Theory is that information is hiding in public. Expert networks to ferret out the public information is the secret to success. Usually, there is a bright line--that is, no peek at proprietary competitive information that is unethical or illegal is permitted--but often the line gets blurred, the rules change [sometimes in mid-stream], or international ambiguity [read: culture] mislevels the playing field.
Guardianship of such corruption is no small matter. Just refer to the infamous USAF refueling tanker competition for many "don't do this" examples.
The execution project
No project of any scale operates without interpersonal relationships, a dollop of politics, and the obscure actions of many people working on their part. Enter: "expert networks". The project manager for sure, work stream managers, and cost account managers all 'work their networks': up and out to the sponsors, and down and in to the worker-bees.
Assembling the mosaic
For those experienced in brainstorming, assembling a mosiac from an expert network is really no different.
First, the science:
Like items are grouped
Relationships are labeled
Sequencing is labeled
Small items are grouped under bigger items
Gaps are identified; gap filler plans are formulated
Narrative headlines are written
Then, the art:
Interpretations are made; the 'big picture' emerges from the 'pixels'
Importance and urgency are weighed
Actionable 'intelligence' is separated for execution plans
Finally: act on the intelligence!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Wednesday, December 22, 2010
Quotation for project managers
A word from Henry Ford:
Thanks to Luis Coehlo at "ah-ha-moments.net" for this bit of wisdom.
In later years, this went on to "Quality is Job One", but then Ford lost the recipe. Now, in a resurgence of Henry's guidance, Ford is regaining the high ground, in part because of a commitment to quality, and part because of another piece of ageless advice:
Of course, simple and complex are not two sides of the same coin. The simplist idea that gets the job done can still be quite complex. My definition of simple is that it's the least complexity that is functionally complete and meets 'quality' measures in the large sense of the word: fitness to form, function, effectiveness, efficiency, availability, etc.
In the December 9th 2010 print edition of "The Economist", there is a great interview--"Ephiphany in Detroit"--with CEO Alan Mullaly on the quality and management turn-around at Ford. It's certainly no secret that many of the things that made Boeing a great aircraft innovator, developer, and production house are being applied at Ford.
There's a lesson to be read about in this interview for all program managers tagged with turning around a project with quality problems.
It's no secret that the first thing Mullaly did to get on top of quality was insist on candid discussion from his functional managers and to instill a culture of safety from prosecution if a problem werre raised. The second thing he did was tune-in to what outside objective evaluators have to say; again, he changed the culture from defense to offense.
So, communicating was a big stick. There's no doubt that "communication in a commonly understood language is the key that unlocks the culture". [This I paraphrase from the US Ambassordor to China from a recent interview on Charlie Rose]
Bookmark this on Delicious
"Quality means doing it right when no one is looking".
Thanks to Luis Coehlo at "ah-ha-moments.net" for this bit of wisdom.
In later years, this went on to "Quality is Job One", but then Ford lost the recipe. Now, in a resurgence of Henry's guidance, Ford is regaining the high ground, in part because of a commitment to quality, and part because of another piece of ageless advice:
Keep it simple, stupid!
Of course, simple and complex are not two sides of the same coin. The simplist idea that gets the job done can still be quite complex. My definition of simple is that it's the least complexity that is functionally complete and meets 'quality' measures in the large sense of the word: fitness to form, function, effectiveness, efficiency, availability, etc.
In the December 9th 2010 print edition of "The Economist", there is a great interview--"Ephiphany in Detroit"--with CEO Alan Mullaly on the quality and management turn-around at Ford. It's certainly no secret that many of the things that made Boeing a great aircraft innovator, developer, and production house are being applied at Ford.
There's a lesson to be read about in this interview for all program managers tagged with turning around a project with quality problems.
It's no secret that the first thing Mullaly did to get on top of quality was insist on candid discussion from his functional managers and to instill a culture of safety from prosecution if a problem werre raised. The second thing he did was tune-in to what outside objective evaluators have to say; again, he changed the culture from defense to offense.
So, communicating was a big stick. There's no doubt that "communication in a commonly understood language is the key that unlocks the culture". [This I paraphrase from the US Ambassordor to China from a recent interview on Charlie Rose]
Are you on LinkedIn? Share this article with your network by clicking on the link.
Tuesday, December 21, 2010
Risk informed decision making
At NASA's risk management homepage you can navigate to a paper on risk informed decision making. As defined there:
Probably the most useful idea in this paper is that risk-informed is different from risk-based. The former takes risk into consideration; the latter adjusts all values for risk and makes a utility decision.
In effect, although some quantitative models are introduced and suggested, the main idea is that risk informs decision making but there are other factors that may intervene and override. Just common sense, really.
Nevertheless, the paper proposes three big steps that are useful to review:
1. Formulation and Selection of Decision Alternatives: In this step the decision alternatives are generated by quantitative and qualitative analyses, past experience, as well as engineering judgment. Unacceptable alternatives are removed after deliberation
2. Analysis and Ranking of Decision Alternatives -- In this step, the screened alternatives are ranked
3. Actual Decision making -- The final decision can be made only after a deliberation takes place (that is, we are describing a risk-informed rather than risk-based process). Deliberation is necessary because there may be aspects of the particular decision that cannot be considered in a formal way.
Bookmark this on Delicious
Risk-informed decision making, as described in this paper, is
the formal process of analyzing various decision alternatives with respect to their impact on the PMs, of
assessing uncertainty associated with their degree of impact, and of selecting the optimal decision
alternative using formal decision theory and taking into consideration program constrains, stakeholder
expectations, and the magnitude of uncertainties.
Probably the most useful idea in this paper is that risk-informed is different from risk-based. The former takes risk into consideration; the latter adjusts all values for risk and makes a utility decision.
In effect, although some quantitative models are introduced and suggested, the main idea is that risk informs decision making but there are other factors that may intervene and override. Just common sense, really.
Nevertheless, the paper proposes three big steps that are useful to review:
1. Formulation and Selection of Decision Alternatives: In this step the decision alternatives are generated by quantitative and qualitative analyses, past experience, as well as engineering judgment. Unacceptable alternatives are removed after deliberation
2. Analysis and Ranking of Decision Alternatives -- In this step, the screened alternatives are ranked
3. Actual Decision making -- The final decision can be made only after a deliberation takes place (that is, we are describing a risk-informed rather than risk-based process). Deliberation is necessary because there may be aspects of the particular decision that cannot be considered in a formal way.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Subscribe to:
Posts (Atom)