Happy Halloween!
Monday, October 31, 2011
Saturday, October 29, 2011
Too much already!
Mike Clayton at Shift Happens! has a nice post on portfolio prioritization. He asks this question:
Why do so many Organisations Resist Rationalising their Project Portfolios?And, then he answers his own question with five reasons:
- Patronage
- It's all too difficult
- Is it really essential?
- Loss aversion
- Lessons unlearned
1.Lack of clear links between the project and the organisation’s key strategic priorities, including agreed measures of success.
2.Lack of clear senior management and Ministerial ownership and leadership.
3.Lack of effective engagement with stakeholders..
4.Lack of skills and proven approach to project management and risk management.
5.Too little attention to breaking development and implementation into manageable steps.
6.Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7.Lack of understanding of, and contact with the supply industry at senior levels in the organisation.
8.Lack of effective project team integration between clients, the supplier team and the supply chain.
Thursday, October 27, 2011
A great place to work
Over at HBR Blog, Tony Schwartz waxes on the 12 Attributes of a Truly Great Place to Work. We've all seen lists like this one, but take a look at some of the comments to the blog. They are both amusing (as in: fire yourself before they can) and insightful (like, it's all about trust)
Admittedly, the first six are a little expensive for many and assume a brick-and-mortar environment, (provide a gym, and provide good food in the cafeteria) but the universally applicable advice gets started in number 7.
However, I skip all the way to 11 (provide learning and skill development opportunity) and 12 (stand for something besides profit--which I take to be a surrogate concept since there are non-profits and government units that can benefit from this list)
In my mind, to not be constantly learning is to be going backward, and backward is not forward to a better future. And, surely, even if the business of business is business (I think a CEO of Coke said that), there's got to be more to it than that, although I admit that the business of business is not God and Country. When I moved from the DoD to private industry, I learned that pretty quick!
Admittedly, the first six are a little expensive for many and assume a brick-and-mortar environment, (provide a gym, and provide good food in the cafeteria) but the universally applicable advice gets started in number 7.
However, I skip all the way to 11 (provide learning and skill development opportunity) and 12 (stand for something besides profit--which I take to be a surrogate concept since there are non-profits and government units that can benefit from this list)
In my mind, to not be constantly learning is to be going backward, and backward is not forward to a better future. And, surely, even if the business of business is business (I think a CEO of Coke said that), there's got to be more to it than that, although I admit that the business of business is not God and Country. When I moved from the DoD to private industry, I learned that pretty quick!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Tuesday, October 25, 2011
Quote of the day
“You know, it’s O.K. to head out for wonderful, but on your way to wonderful, you’re going to have to pass through all right, and when you get to all right, take a good look around and get used to it because that may be as far as you’re going to get
Bill Withers, R&B singer and philosopher
Perhaps a more complicated rendering of "best is the enemy of better", but a more elegant statement, to be sure.
Sunday, October 23, 2011
Is everything a hammer?
Well, our friends at Dark Matter have raised another issue that we found provoking, to wit: have we gone too far in some cases with the visual display thing? In other words, having invented the hammer, do we use it for everything? All the world is not a nail, afterall, so perhaps some pause is warranted.
Now, to be fair, the Dark Matter crowd is all about safety, complexity, and and technology risk, especially as it affects human reactions in human-system situations. So naturally, Dark Matter is all over this stuff.
On the other had, as project managers (rather than system engineers) we have some obligation to test and challenge the various solutions, even we don't have the competence to rule things in or out. It's sort of the project equivalent of "reign but does not rule".
Setting up independent design review boards--sort of the red team equivalent for proposals--with 'grey beards' to give independent opinion is one way to do it. (Does everyone recognize the term 'grey beard' or am I dating myself?)
In the post that got our attention, the issue was the elimination of certain tactile responses replaced by visual indicators. The case in point is the stall indication on the Airbus that crashed near Brazil a couple of years ago. The traditional "stick shaker" had been eliminated, as well as some other traditional tactile oriented systems.
There are all kinds of stories like this. In Gene Kranz's book "Failure is not an option" he describes similar debates between the rulers and the reigners. There was a lot at stake.
This stuff is not to be taken lightly, and certainly not to be delegated to self-appointed teams without a disciplined tie to established saftey regimes.
Bookmark this on Delicious
Now, to be fair, the Dark Matter crowd is all about safety, complexity, and and technology risk, especially as it affects human reactions in human-system situations. So naturally, Dark Matter is all over this stuff.
On the other had, as project managers (rather than system engineers) we have some obligation to test and challenge the various solutions, even we don't have the competence to rule things in or out. It's sort of the project equivalent of "reign but does not rule".
Setting up independent design review boards--sort of the red team equivalent for proposals--with 'grey beards' to give independent opinion is one way to do it. (Does everyone recognize the term 'grey beard' or am I dating myself?)
In the post that got our attention, the issue was the elimination of certain tactile responses replaced by visual indicators. The case in point is the stall indication on the Airbus that crashed near Brazil a couple of years ago. The traditional "stick shaker" had been eliminated, as well as some other traditional tactile oriented systems.
There are all kinds of stories like this. In Gene Kranz's book "Failure is not an option" he describes similar debates between the rulers and the reigners. There was a lot at stake.
This stuff is not to be taken lightly, and certainly not to be delegated to self-appointed teams without a disciplined tie to established saftey regimes.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Friday, October 21, 2011
Those process guys!
I was musing with a colleague the other day about "those process guys" who sometimes miss this bit of wit:
In any event, to give my friend a concrete example, I told him about a study I did on "the cost of a memo", circa mid-late '80's that goes like this:
This arc took about 8 years to execute as we learned that with technology the idea is not to replace item for item in the process; it's to ditch the process and do something different with the technology.
I call this distructive improvement, but others talk about distructive innovation.
And we learned this lesson: putting in a bunch of IT personal application tools that save 10min here and there may not result in any real productivity or cost savings. It's rare that all these little segments coherently add to one headcount that can be released. You can't fire or transfer an FTE, only an integer person. So, as we saw in the 80's, and to some degree the cycle is beginning again, especially with ERP installs, there is capital spending without commensurate return to the business.
Another example, not project management, and further back: the transistor originally just replaced the triode tube, but the circuit design and functionality were not that much different. It wasn't until we grasped the idea that the transistor was a lot more than a 3 pin replacement for 3 pin tube did the whole digital productivity thing take off.
In any event: remember the wise words: It's often better to do away with the trains than to spend the effort to make them run on time!
Bookmark this on Delicious
Are you on LinkedIn? Share this article with your network by clicking on the link.
Rather than make the trains run on time, it may be better to do away the trains altogetherI acutally think I read an interview with Steve Balmer of Microsoft where he said something like that, but I don't think he took his own advice.
In any event, to give my friend a concrete example, I told him about a study I did on "the cost of a memo", circa mid-late '80's that goes like this:
- In the beginning, there was no personal computer. As a director, I wrote memo's to my staff in long hand (I hear that is no longer taught in school) and gave the scratch to my personal secretary to type on a Selectric with correcting tape. She then gave me the typed copy to edit, retyped it for my signature, and then she printed and distributed the memo through the office mail. I calculated the cost of a one page memo at about $50. (I may have under calculated, upon reflection, but this was '85 or thereabouts, so we worked cheap then)
- Sometime in the mid to late 80's, I bought my secretary a Mac and printer to replace the typewriter, but otherwise the process was the same. Cost went up to $60 to pay for the hardware.
- Then, I bought myself a Mac and I could type the memo and send it to her for editing and printing. The process saved a few minutes of my time but we had an extra computer, so the cost of a memo is now about $70. A lot of IT spending so far, no productivity gain, and a greater expense. General manager is not happy!
- Then came email networking adoption, and I could mail the memo myself. The cost has not gone down, still $70, but now the secretary has idle time (charged to the cost of a memo since the charges have to go somewhere). You can't fire part of a person, so we had to find something else for her to do.
- Then, memo's went out of style, replaced by the world of casual email correspondence. My time dropped a lot (per memo/email), so the cost per email dropped to about half or less of the formal memo, call it $30.
- Then, finally, with nothing to do, replaced by calendar applications and email, we fired the secretary, and the cost dropped again to about $10.
This arc took about 8 years to execute as we learned that with technology the idea is not to replace item for item in the process; it's to ditch the process and do something different with the technology.
I call this distructive improvement, but others talk about distructive innovation.
And we learned this lesson: putting in a bunch of IT personal application tools that save 10min here and there may not result in any real productivity or cost savings. It's rare that all these little segments coherently add to one headcount that can be released. You can't fire or transfer an FTE, only an integer person. So, as we saw in the 80's, and to some degree the cycle is beginning again, especially with ERP installs, there is capital spending without commensurate return to the business.
Another example, not project management, and further back: the transistor originally just replaced the triode tube, but the circuit design and functionality were not that much different. It wasn't until we grasped the idea that the transistor was a lot more than a 3 pin replacement for 3 pin tube did the whole digital productivity thing take off.
In any event: remember the wise words: It's often better to do away with the trains than to spend the effort to make them run on time!
Wednesday, October 19, 2011
Frank Gehry on projects
I love architecture, though I'm not an architect, and never studied architecture. Of course, I love system architecture, which is both different from building and construction per se, and identical because a building is a system just as any other such integrated structure is a system.
Frank Gehry is one of Canada-America's more esteemed architects. He does projects around the world. The picture is of the museum in Bilbao, Spain. Of course, Gehry always designs some pretty unusual stuff, but in an interesting interview on cnn.com/gps for September 4, 2011, he says about his projects:
Some of these problems are like any 'new to the world' endeavor: stuff happens! But some is just downright delusional or deliberately deceptive. Some advice just never gets old: Buyer beware!
Bookmark this on Delicious
Frank Gehry is one of Canada-America's more esteemed architects. He does projects around the world. The picture is of the museum in Bilbao, Spain. Of course, Gehry always designs some pretty unusual stuff, but in an interesting interview on cnn.com/gps for September 4, 2011, he says about his projects:
- He's very thorough with the envisioning and conceptualization, often building 100 models before he 'sees' it. (Spiral, anyone?)
- Everything he does has customer buy-in, and in the end, the customer never regrets (Sounds like an embedded agile customer)
- The building has to work functionally (wow! it has to work. Have the ERP guys heard that one?)
- You have to be able to actually build it, meaning it has to be technologically feasible and feasibly economical (perhaps we should revisit the Sydney opera house--not a Gehry design), and
- It has to meet a budget! (Back to PM 101, and the consequences of "other people's money")
Some of these problems are like any 'new to the world' endeavor: stuff happens! But some is just downright delusional or deliberately deceptive. Some advice just never gets old: Buyer beware!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Monday, October 17, 2011
Density and productivity
I just learned (silly me for not knowing) that it takes density to get decent productivity. And policies that discourage density have a likely unintended consequence of squeezing off improved productivity. This seems to be the message from Ryan Avent
In cities and urban areas, his advice is don't discourage growth, or least make it affordable for more people to join in the high production center. Dis-affordability, we are told, ultimately leads to declining, or least not improving productivity.
So, now transfer this to the project domain. (Notice: switching domains is often problematic and solutions often simply don't transfer. However, Avent himself brings up the topic of work productivity vs distribution, so perhaps I'm not too far off base). The thing that jumps to mind is the co-located team, a favorite if not a mandate for the agile community, and the distributed or virtual team, a favorite if not a mandate for the project at enterprise scale.
The conclusion is begged by the set-up: we should either expect a certain productivity premium for the co-located team, or on the flip side, we should expect to discount the productivity of a distributed or virtual team. Whether discount or premium depends on where the baseline is. From my experience, working mostly in larger scale enterprises, the baseline is the distributed team, so I see a premium for the co-location case.
So, in the context of "density begets productivity", I'm probably taking the right view. Co-locating, where possible, show pay a productivity dividend. However, reversing seven decades of ever larger scale--since the onset of WW II in 1940--is no small matter, and probably not desirable or practical. If we going to "go big" as the popular refrain goes, we're going to need big, distributed teams. We're unlikely to use agile methods to build Hoover Dam or the Golden Gate bridge (projects in the 1930's, and unprecedented in scope for the time, and pretty impressive, even today)
What's to do? Distributed teams are less productive, but necessary in most cases to get true scale. The important thing is have the right reference class for estimating. Obviously, the reference class should be one that likely has all the productivity discounts built in, else an underestimate is almost a foregone conclusion.
Bookmark this on Delicious
In cities and urban areas, his advice is don't discourage growth, or least make it affordable for more people to join in the high production center. Dis-affordability, we are told, ultimately leads to declining, or least not improving productivity.
So, now transfer this to the project domain. (Notice: switching domains is often problematic and solutions often simply don't transfer. However, Avent himself brings up the topic of work productivity vs distribution, so perhaps I'm not too far off base). The thing that jumps to mind is the co-located team, a favorite if not a mandate for the agile community, and the distributed or virtual team, a favorite if not a mandate for the project at enterprise scale.
The conclusion is begged by the set-up: we should either expect a certain productivity premium for the co-located team, or on the flip side, we should expect to discount the productivity of a distributed or virtual team. Whether discount or premium depends on where the baseline is. From my experience, working mostly in larger scale enterprises, the baseline is the distributed team, so I see a premium for the co-location case.
So, in the context of "density begets productivity", I'm probably taking the right view. Co-locating, where possible, show pay a productivity dividend. However, reversing seven decades of ever larger scale--since the onset of WW II in 1940--is no small matter, and probably not desirable or practical. If we going to "go big" as the popular refrain goes, we're going to need big, distributed teams. We're unlikely to use agile methods to build Hoover Dam or the Golden Gate bridge (projects in the 1930's, and unprecedented in scope for the time, and pretty impressive, even today)
What's to do? Distributed teams are less productive, but necessary in most cases to get true scale. The important thing is have the right reference class for estimating. Obviously, the reference class should be one that likely has all the productivity discounts built in, else an underestimate is almost a foregone conclusion.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Saturday, October 15, 2011
The courtesy of a reply
How can it be in this time of instant everything, especially communication, that communication courtesy is so lacking? Isn't closing the loop and acknowledging an exchange the essence of quality--relationship quality--and isn't quality what we are constantly striving for?
Quality is the prime motivator of the agilists
Lack of quality almost pushed American manufacturing to extinction
Have we gone over the top? There is so much communication that no one is communicating? A paradox, to be sure. I don't know. It just seems to me that the courtesy of a reply is a small matter with such large leverage. I know we are supposed to be in an age of "de-leveraging", but really I think de-leveraging in communications is a bridge too far!
(Full disclosure: I often don't return unsolicited sales calls .... admittedly, an exception to my rant, but having worked with a sales company for a few years, I understand sales people live a life of 'rejection')
Bookmark this on Deliciousdiv>
Are you on LinkedIn? Share this article with your network by clicking on the link.
Thursday, October 13, 2011
Complicated, complex, and complex adaptive
"Complicated, complex, and complex adaptive": We see these terms a lot in the project business. I'm ok with the first two; the last one is a bit dubious for project managers in my opinion.
Here's some definitions. The first is taken from an interview with Michael J. Mauboussin by Tim Sullivan in the September 2011 edition of the Harvard Business Review, an issue that is dedicated to complexity:
And here's by Gökçe Sargut and Rita Gunther McGrath writing in an article in the same issue on the difference between complicated and complex:
Complicated systems, they say, have a lot of parts, but the parts interact in patterns of behavior we know and understand, and can reasonably predict.
Complex systems are versions of complicated systems wherein the patterns are there but difficult to know about (too many, too obscure, or outside our normal experience) and the interactions, though predictable, are too difficult to predict as a practical matter.
They observe:
Well, I buy the complex and complicated thing, but every example of CAS that anyone gives is more often biological than not. After all, the biological sciences has been the doman that has advanced the study of CAS the most.
What about agile?
Many say agile methods are themselves an example of CAS because of the property of emergence, and the myriad of agents (developers, testers, stakeholders, sponsors, customers, users et al) that are in constant interaction. Perhaps so. But I don't see agile projects and ant colonies acting the same way. There's simply too many intervening structures, inhibitions, rules, and constraints, to say nothing of project charters, vision, product managers, and market forces that focus the project.
As others have said, it's often nonsensical and many times misleading to cross domains too readily. For my money, I buy into emergence, and I buy into output effecting input (a necessary condition for adaption), but most of the other biological instinctive and survival behavior of ants is not what projects are about.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Here's some definitions. The first is taken from an interview with Michael J. Mauboussin by Tim Sullivan in the September 2011 edition of the Harvard Business Review, an issue that is dedicated to complexity:
A complex adaptive system (CAS) has three characteristics. The first is that the system consists of a number of heterogeneous agents, and each of those agents makes decisions about how to behave. The most important dimension here is that those decisions will evolve over time. The second characteristic is that the agents interact with one another. That interaction leads to the third—something that scientists call emergence: In a very real way, the whole becomes greater than the sum of the parts. The key issue is that you can’t really understand the whole system by simply looking at its individual parts.
And here's by Gökçe Sargut and Rita Gunther McGrath writing in an article in the same issue on the difference between complicated and complex:
Complicated systems, they say, have a lot of parts, but the parts interact in patterns of behavior we know and understand, and can reasonably predict.
Complex systems are versions of complicated systems wherein the patterns are there but difficult to know about (too many, too obscure, or outside our normal experience) and the interactions, though predictable, are too difficult to predict as a practical matter.
They observe:
Complex systems have always existed, of course—and business life has always featured the unpredictable, the surprising, and the unexpected. But complexity has gone from something found mainly in large systems, such as cities, to something that affects almost everything we touch: the products we design, the jobs we do every day, and the organizations we oversee.
Well, I buy the complex and complicated thing, but every example of CAS that anyone gives is more often biological than not. After all, the biological sciences has been the doman that has advanced the study of CAS the most.
What about agile?
Many say agile methods are themselves an example of CAS because of the property of emergence, and the myriad of agents (developers, testers, stakeholders, sponsors, customers, users et al) that are in constant interaction. Perhaps so. But I don't see agile projects and ant colonies acting the same way. There's simply too many intervening structures, inhibitions, rules, and constraints, to say nothing of project charters, vision, product managers, and market forces that focus the project.
As others have said, it's often nonsensical and many times misleading to cross domains too readily. For my money, I buy into emergence, and I buy into output effecting input (a necessary condition for adaption), but most of the other biological instinctive and survival behavior of ants is not what projects are about.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Tuesday, October 11, 2011
Traps when thinking in systems
Here's an abridged list of 'traps' she cautions against, a list of ills we should all be cautious about:
Success to the successfulAre you on LinkedIn? Share this article with your network by clicking on the link.
If the winners of a competition are systematically rewarded with the means to win again, a reinforcing feedback loop is created by which, if it is allowed to proceed uninhibited, the winners eventually take all, while the losers are eliminated.
The Tragedy of the Commons
When there is a commonly shared resource, every user benefits directly from its use, but shares the costs of its abuse with everyone else. Therefore, there is very weak feedback from the condition of the resource to the decisions of the resource users. The consequence is overuse of the resource, eroding it until it becomes unavailable to anyone.
Drift to Low Performance
Allowing performance standards to be influenced by past performance, especially if there is a negative bias in perceiving past performance, sets up a reinforcing feedback loop of eroding goals that sets a system drifting toward low performance.
Rule Beating Trap
Rules to govern a system can lead to rule-beating-perverse behavior that gives the appearance of obeying the rules or achieving the goals, but that actually distorts the system. Rule beating is usually a response of the lower levels in a hierarchy to overrigid, deleterious, unworkable, or ill-defined rules from above.
Seeking the Wrong Goal
System behavior is particularly sensitive to the goals of feedback loops. If the goals-the indicators of satisfaction of the rules-are defined inaccurately or incompletely, the system may obediently work to produce a result that is not really intended or wanted.
Sunday, October 9, 2011
The forest for the trees
We are all taught from the first moment that the way to eat an elephant is one bite at a time. That is: to work on a complex problem, always start by simplifying the task by decomposition, disaggregation, and separation of the trees from the forest.
Ok, but what about this: (think: object = tree; distant background = forest)
In a posting on "Azimuth", John Baez has a part I discussion of evolution in complex systems from which the diagram, above, is taken.
In addition to the distortion arising from the point of view from which data is viewed, he goes on to caution about the the Dunning-Krueger effect (the uninformed, misinformed, and ignorant are biased to not understand their own cognitive deficiencies), saying, in part:
But, it's not only trees: it's also use cases and user stories, and then ultimately Test-Driven-Development scripts, all decompositions that have the potential to alter perspective.
Thus, constant attention to "re-composition" to validate low level requirements with high level vision is necessary. That is the essence of the "V-Model", a bit of system engineering that we can all take advantage.
Bookmark this on Delicious
Are you on LinkedIn? Share this article with your network by clicking on the link.
Ok, but what about this: (think: object = tree; distant background = forest)
In a posting on "Azimuth", John Baez has a part I discussion of evolution in complex systems from which the diagram, above, is taken.
In addition to the distortion arising from the point of view from which data is viewed, he goes on to caution about the the Dunning-Krueger effect (the uninformed, misinformed, and ignorant are biased to not understand their own cognitive deficiencies), saying, in part:
... if we don’t understand a system well from the start, we may overestimate how well we understand the limitations inherent to the simplifications we employ in studying it.
But, it's not only trees: it's also use cases and user stories, and then ultimately Test-Driven-Development scripts, all decompositions that have the potential to alter perspective.
Thus, constant attention to "re-composition" to validate low level requirements with high level vision is necessary. That is the essence of the "V-Model", a bit of system engineering that we can all take advantage.
Bookmark this on Delicious
Friday, October 7, 2011
To Push or not to Push
A lot's been written about Steve Jobs' legacy at Apple since his decision last month to step down from CEO and remain only as chairman. Unfortunately, Jobs died Oct 5th.
Among the anecdotes told and retold is his oft repeated anti-LEAN doctrine: features and functions are to the PUSHED to the customer because, he says:
And it's not only Apple. Sony has also been said to have not consulted any outsiders regarding the Walkman. Again, when it's "new to the world", what's a consumer to say? Hit, or no hit?
Well, what would the LEANers say about that? The Lean mantra, of course, is to pull consumer requirements from the customer, not push them (arrogantly) from the developers/stakeholders to the consumer.
And, what would the agilists say? Apple most assuredly does not embed customers/users on its product teams. They, perhaps as much as any competitive innovator, guards their intellectual property and marketing plans as closely as any. One only needs to go back to the infamous case of the lost/stollen iPhone prototype to see them in action.
That's not to say that a product manager internal to the company is not closely consulted on new products, but on the most important features and functions, hardly any less than Mr Jobs himself makes the final decisions. Others need not apply
Conclusion: Alistair Cockburn may have been spot on when he said: any methodology can be made to succeed in some situations; any methodology can fail. Perhaps, as it always has been: inspirational vision, leadership, commitment, and methodology.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Among the anecdotes told and retold is his oft repeated anti-LEAN doctrine: features and functions are to the PUSHED to the customer because, he says:
It’s not the consumer’s job to know what they want
And it's not only Apple. Sony has also been said to have not consulted any outsiders regarding the Walkman. Again, when it's "new to the world", what's a consumer to say? Hit, or no hit?
Well, what would the LEANers say about that? The Lean mantra, of course, is to pull consumer requirements from the customer, not push them (arrogantly) from the developers/stakeholders to the consumer.
And, what would the agilists say? Apple most assuredly does not embed customers/users on its product teams. They, perhaps as much as any competitive innovator, guards their intellectual property and marketing plans as closely as any. One only needs to go back to the infamous case of the lost/stollen iPhone prototype to see them in action.
That's not to say that a product manager internal to the company is not closely consulted on new products, but on the most important features and functions, hardly any less than Mr Jobs himself makes the final decisions. Others need not apply
Conclusion: Alistair Cockburn may have been spot on when he said: any methodology can be made to succeed in some situations; any methodology can fail. Perhaps, as it always has been: inspirational vision, leadership, commitment, and methodology.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Wednesday, October 5, 2011
Now on Kindle
Just search the Kindle Store for "blog john goodpasture", and you'll get there.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Monday, October 3, 2011
Sins of progress
Paul Solomon, an industry guru in earned value, has an article in a recent edition of the "Journal of Software Technology" (August, 2011, vol 14, number 3) that lists a number of sins that distort progress. I'm sure of none of you reading have done these things, but I repeat Paul's list so you can be aware.
Among his observations and examples of misuse and abuse of the project's management reserve (MR), he lists these tricks (paraphrased and translated for the non-defense project audience, so these are not a direct quote of Solomon's remarks)
So, you might ask: what's the management reserve for if not to fund problems not foreseen? That's Paul's point exactly: rework--at least to some extent--should be in the baseline so that the project's cost is not a matter of deliberate deception. So also for the other practices. In other words, trust and integrity, so valued in the implementing teams, starts at the top. No news there, but never a bad thing to review.
Of course, these practices are not exclusively in the defense domain. Try big time construction if you want more examples. This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"
Good grief! Is there no one on top of this?
Bookmark this on Delicious
Among his observations and examples of misuse and abuse of the project's management reserve (MR), he lists these tricks (paraphrased and translated for the non-defense project audience, so these are not a direct quote of Solomon's remarks)
Rework--in other words, error of feature, function, or performance requiring correction--is not included in the budget (though it's reasonable to expect some rework as part of the natural variation in the design and development processes). Rework is identified as a risk (on the risk register) and money to fund the risk response is included in management reserve (MR). Later, funding is transferred from the reserve to the budget when the design or test item does not meet, or no longer meets, technical requirements.
Cost drivers such as software lines of code (LOC), number of drawings, hours per drawing or per LOC, are understated (justified as aggressive interpretation of bottom up estimates) compared with empirical data and realistic estimates. The low ball estimate is called “management challenge” and identified as a risk, not an issue. Later, funding from the management reserve is transferred to the budget to cover the risk.
The same conditions exist, as above, but no “risk” was identified. Instead, the additional iterations are called “scope growth” even though the basic tasks were planned in the budget
The number of tests (and resultant rework and problem reports) is understated based on realistic estimates and empirical data. Later, the tests and rework needed to meet technical requirements are funded from MR as “additional scope” even though the customer requirements are stable.
Work that could not be completed internally is transferred to a supplier. MR is used under the pretext that it is “additional scope” or “unplanned.”
So, you might ask: what's the management reserve for if not to fund problems not foreseen? That's Paul's point exactly: rework--at least to some extent--should be in the baseline so that the project's cost is not a matter of deliberate deception. So also for the other practices. In other words, trust and integrity, so valued in the implementing teams, starts at the top. No news there, but never a bad thing to review.
Of course, these practices are not exclusively in the defense domain. Try big time construction if you want more examples. This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"
Good grief! Is there no one on top of this?
Are you on LinkedIn? Share this article with your network by clicking on the link.
Saturday, October 1, 2011
Quotation for today
Did you know this little tidbit?
Need an example? Consider Salman Khan, an MIT graduate, who went from school to Wall Street. But after a few years, found himself doing something a lot more useful: he founded the Khan Academy.
Would that others follow in his footsteps!
Bookmark this on Delicious
Wall Street hires more math, engineering and science graduates than the semiconductor industry, Big Pharma or the telecommunications business
Need an example? Consider Salman Khan, an MIT graduate, who went from school to Wall Street. But after a few years, found himself doing something a lot more useful: he founded the Khan Academy.
Would that others follow in his footsteps!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Subscribe to:
Posts (Atom)