Mike makes some good points. Give it a read
Are you on LinkedIn? Share this article with your network by clicking on the link.
Saturday, October 30, 2010
The vision thing
Earlier this year Mike Clayton had a nice post on the the vision thing. His point: vision is important enough that we should all take a few extra minutes to write something truly meaningful, else don't bother.
Mike makes some good points. Give it a read
Bookmark this on Delicious
Mike makes some good points. Give it a read
Thursday, October 28, 2010
Process projects Part II "As Is" hints
In Part II of this series, I take up a few key questions and hints for the to-do list for the "AS IS" analysts. {hint about the 'hints': you might want to take a look at Part I to get some of the jargon used here}
Bookmark this on Delicious
- Identify all the verticals in each process; each stakeholder of a vertical could be a nemesis, but at the very least represents an 'authority' that may have to be addressed in workflow.
- Identify all the authorities that flow across the vertical boundaries, and other boundary properties--timing, data, data transforms required
- Look at any required functionalities at the vertical interfaces within the process. [To make an end to end process, there are often multiple data transformations and other interface services to get the end to end to flow]
- Tag processes that are 'certified' by an external authority [ISO, auditors, etc] and get specifics about what must be maintained to keep the certification or audit integrity
- Tag processes are certified internally and re-up the business justification for these
- Identify processes that must be TRUSTED for pay or other.
- Answer the question: Does there really need to be configuration control on untrusted processes?
- As improvement targets, develop a list of process properties that are below some standard [cost, quality, etc]
- Examine the TOC issues at the process boundaries with the verticals. How is the constraint managed, if at all?
- What tradeoff is the executives prepared to make between innovation and process configuration control? That is, the bane of process control is that it over-centralizes, introduces too much command and control, is not agile, and removes incentives for innovation
Are you on LinkedIn? Share this article with your network by clicking on the link.
Tuesday, October 26, 2010
Process projects Part 1
If you're running a project to do process design and implement wide sweeping change, you might run into the same issues I have:
Show me the money!
Companies are run vertically. Processes are horizontal. The impact is that all the P&L results, bonus', and external [and usually internal] certifications are in the vertical dimension. Rarely does such exists for the horizontal process dimension. Impact? There's no constituency 'paid' on process success per se! So, there's little political support for the process dimension.
Interfaces?
Another impact is that if you create a process breakdown structure [PBS], what you find is that most processes, insofar as they are formally defined at all, do not interface well across the vertical boundaries. It's like railroad tracks that don't meet or they have different gauges as they transition across the verticals.
One thing that does work is to write formal ICD's [interface control document] for each horizontal intersection with a vertical. ICD's define not only workflow across the boundary, what data was passed, management authorities that flow across boundaries, timing, and error conditions/responses.
TRUSTED data
P&L's are 'validated' [a term of art in the IT world] in the vertical organization, thereby TRUSTED for pay purposes. There no such trusted definition or data model for processes. Pay..bonus'...etc follow the P&L, not the process. So, the process can be violated at will so long as the P&L is not.
Data definitions?
All business run on data, but few business' have a formal data model or any means to maintain configuration and definition. Data is primarily organized [and defined] in each vertical to serve the P&L and business certification requirements. As such, the same data item may not mean the same thing in every vertical. Thus, when you try to apply data throughout a horizontal, the data doesn't match or even make sense in many cases.
Customer?
A good ice breaker on the data issue is have the process design "As Is" analysts define 'customer'. For most companies, there will be a half dozen definitions, all different. The sales customer, the service customer, the A/R customer, and so forth. And customer is often location [address] and sometimes entity [company]. Some companies separate customer from user; others dont'.
Process P&L
One thing that will drive a process project nuts [and is very expensive to do] is after doing the [horizontal] process maps, try to find the cost of the process and compare that to the cost of the [vertical] "As Is" business. This is an exercise in rationalizing horizontal and vertical sums. This activity is almost never successful in the timeframe of a project. See other comments above.
I wish this were the end of it, but no: there's more in subsequent postings.
Bookmark this on Delicious
Show me the money!
Companies are run vertically. Processes are horizontal. The impact is that all the P&L results, bonus', and external [and usually internal] certifications are in the vertical dimension. Rarely does such exists for the horizontal process dimension. Impact? There's no constituency 'paid' on process success per se! So, there's little political support for the process dimension.
Interfaces?
Another impact is that if you create a process breakdown structure [PBS], what you find is that most processes, insofar as they are formally defined at all, do not interface well across the vertical boundaries. It's like railroad tracks that don't meet or they have different gauges as they transition across the verticals.
One thing that does work is to write formal ICD's [interface control document] for each horizontal intersection with a vertical. ICD's define not only workflow across the boundary, what data was passed, management authorities that flow across boundaries, timing, and error conditions/responses.
TRUSTED data
P&L's are 'validated' [a term of art in the IT world] in the vertical organization, thereby TRUSTED for pay purposes. There no such trusted definition or data model for processes. Pay..bonus'...etc follow the P&L, not the process. So, the process can be violated at will so long as the P&L is not.
Data definitions?
All business run on data, but few business' have a formal data model or any means to maintain configuration and definition. Data is primarily organized [and defined] in each vertical to serve the P&L and business certification requirements. As such, the same data item may not mean the same thing in every vertical. Thus, when you try to apply data throughout a horizontal, the data doesn't match or even make sense in many cases.
Customer?
A good ice breaker on the data issue is have the process design "As Is" analysts define 'customer'. For most companies, there will be a half dozen definitions, all different. The sales customer, the service customer, the A/R customer, and so forth. And customer is often location [address] and sometimes entity [company]. Some companies separate customer from user; others dont'.
Process P&L
One thing that will drive a process project nuts [and is very expensive to do] is after doing the [horizontal] process maps, try to find the cost of the process and compare that to the cost of the [vertical] "As Is" business. This is an exercise in rationalizing horizontal and vertical sums. This activity is almost never successful in the timeframe of a project. See other comments above.
I wish this were the end of it, but no: there's more in subsequent postings.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Sunday, October 24, 2010
Nash equilibrium Part I
The Nash equilibrium?
The "Nash equilibrium" is a game theory idea that is used to evaluate or forecast the responses of two or more independent, intelligent, and uncoordinated decision makers compelled to participate in solving a common problem or address a common issue.
It is also assumed that in some way the parties are adversaries, and, as a matter of strategy, knowledgeable of the other's likely reactions and preferences.
Does your project face uncoordinated adversaries? I use the word adversary in the sense that each party has interests they feel duty bound to protect; each perceives something to lose if they agree whole heartedly with the other's position.
I use uncoordinated in the sense that each party has a vested interest in being--and maintaining themselves as--an independent decision maker. As such, they address the issue or problem without coordinating their actions in advance with the other party; in fact, they may have no knowledge of when the other party will act. However, there evolves...in the game and in reality....an informal 'order' or sequence to the decision making among parties, although who goes first is often part of the 'game' strategy, given knowledge of the other party's preferences or known reactions.
And, here's another point: each party has little incentive to 'move off' their position once adopted.
Contract negotiations between the project and a contractor, or the project and a customer, come immediately to mind. In theory and practice negotiations are adversarial. And, there is always a strategy of who goes first; and the other's preferences are usually understood in advance.
But all manner of value clashes also come to mind. Stakeholders resist other stakeholders; and stakeholders fuss with the project manager. Here's another example: If you've ever tried to implement wide sweeping change, like installing a system that changes and disrupts myriad processes all at once, you will understand the motiviation for this posting.
So, what is game theory and how does it apply to project management? Game theory posits certain situations are worked somewhat like making moves on a game board. The board is open and evident to all; the rules are known. There are competing interests. However, in most board games, there is a clear winner and a clear loser. In the project domain, the interesting games are the non-zero-sum games where everyone gets something and no one loses everything. Non-zero-sum is particularly the objective in negotiation: everyone needs to walk away with something.
To survive in such a 'game, it's a little like 'reading the defense' when faced with a challenge, threat, or opportunity.
The Nash equilibrium, named for its inventer, Nobel laureate John Nash, presumes that in cases of non-zero-sum--that is, neither party needs to lose and both parties may claim a win--then:
Blinder went on to develop something that has come to be called "Alan Blinder's matrix" that he himself called a 'payoff matrix'. It's described on page 23 of the paper under the link given above.
We'll discuss Blinder's matrix as it applies to project management in the next part in this series
Bookmark this on Delicious
The "Nash equilibrium" is a game theory idea that is used to evaluate or forecast the responses of two or more independent, intelligent, and uncoordinated decision makers compelled to participate in solving a common problem or address a common issue.
It is also assumed that in some way the parties are adversaries, and, as a matter of strategy, knowledgeable of the other's likely reactions and preferences.
Does your project face uncoordinated adversaries? I use the word adversary in the sense that each party has interests they feel duty bound to protect; each perceives something to lose if they agree whole heartedly with the other's position.
I use uncoordinated in the sense that each party has a vested interest in being--and maintaining themselves as--an independent decision maker. As such, they address the issue or problem without coordinating their actions in advance with the other party; in fact, they may have no knowledge of when the other party will act. However, there evolves...in the game and in reality....an informal 'order' or sequence to the decision making among parties, although who goes first is often part of the 'game' strategy, given knowledge of the other party's preferences or known reactions.
And, here's another point: each party has little incentive to 'move off' their position once adopted.
Contract negotiations between the project and a contractor, or the project and a customer, come immediately to mind. In theory and practice negotiations are adversarial. And, there is always a strategy of who goes first; and the other's preferences are usually understood in advance.
But all manner of value clashes also come to mind. Stakeholders resist other stakeholders; and stakeholders fuss with the project manager. Here's another example: If you've ever tried to implement wide sweeping change, like installing a system that changes and disrupts myriad processes all at once, you will understand the motiviation for this posting.
So, what is game theory and how does it apply to project management? Game theory posits certain situations are worked somewhat like making moves on a game board. The board is open and evident to all; the rules are known. There are competing interests. However, in most board games, there is a clear winner and a clear loser. In the project domain, the interesting games are the non-zero-sum games where everyone gets something and no one loses everything. Non-zero-sum is particularly the objective in negotiation: everyone needs to walk away with something.
To survive in such a 'game, it's a little like 'reading the defense' when faced with a challenge, threat, or opportunity.
The Nash equilibrium, named for its inventer, Nobel laureate John Nash, presumes that in cases of non-zero-sum--that is, neither party needs to lose and both parties may claim a win--then:
....each player does what he would if he knew what the other player was going to do. It is an equilibrium in the sense that the two resulting strategies are consistent with one another; once the game is played, neither player has any desire to change his decision. Not all games have a unique Nash equilibrium"according to a 1982 paper by economist Alan Blinder
Blinder went on to develop something that has come to be called "Alan Blinder's matrix" that he himself called a 'payoff matrix'. It's described on page 23 of the paper under the link given above.
We'll discuss Blinder's matrix as it applies to project management in the next part in this series
Friday, October 22, 2010
Wisdom of the quotes
What you are prepared for never happens
Pennsylvania Dutch proverb
Perhaps this idea is why risk managers preach 360 situational awareness. The implication is that we are unprepared for what does happen. So, is there nothing to do, or to be done, to get prepared?
I suggest that when that happens for which we are unprepared, even if it was foreseeable--indeed: foreseen--that it's useful to have protocols in place to handle the ad-hoc networks that form to handle the unexpected.
The worst situation is everyone milling about, no one in charge, and no protocols to put someone in charge.
At the very least, a protocol could exist to form a working group of senior leaders to assess the situation and reform governance so we can move on and address the situation.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Wednesday, October 20, 2010
Isopraxism?
How is isopraxism working for you in your project?
Not sure? Let's take a moment to define the term:
The fact is, this behaviorial attribute is what makes leaders attractive to followers:...it's what infects and affects the followers. It gives rise to team cohesion and a 'all for one' spirit.
If a leader has energy, drive, and confidence, then the phenomenom of isopraxism will transfer those feelings...through a desire to mimic....to the whole team. They say imitation is the highest compliment, but imitation is almost an un-learned and unconscious reaction to a favorable behavior.
Absorbing the leader's traits is what it's all about. It's what make the quarterback essential, but it's what requires that the quarterback hold his head up and be confident in the huddle....any hint of fear or dispair will be picked up and mimicked.
So, if you're the PM and the team is down, discouraged, you need only look to yourself for the fix. You're the leader; isopraxism is the connection!
Bookmark this on Delicious
Not sure? Let's take a moment to define the term:
Imitation 1. "A non-learned neurobehavior in which members of a [team] act in a like manner"
Principle of mimicry 2. Copying, emulating, or aping a behavior, gesture, or fad.
Impulsive tendency 3. To wear the same style of jewelry, clothing, or shoes.
The fact is, this behaviorial attribute is what makes leaders attractive to followers:...it's what infects and affects the followers. It gives rise to team cohesion and a 'all for one' spirit.
If a leader has energy, drive, and confidence, then the phenomenom of isopraxism will transfer those feelings...through a desire to mimic....to the whole team. They say imitation is the highest compliment, but imitation is almost an un-learned and unconscious reaction to a favorable behavior.
Absorbing the leader's traits is what it's all about. It's what make the quarterback essential, but it's what requires that the quarterback hold his head up and be confident in the huddle....any hint of fear or dispair will be picked up and mimicked.
So, if you're the PM and the team is down, discouraged, you need only look to yourself for the fix. You're the leader; isopraxism is the connection!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Monday, October 18, 2010
Post Hoc, Ergo Propter Hoc
Post Hoc, Ergo Propter Hoc
In fact, this error--false cause--is a common confusion between correlation--that is, a relationship--and cause-and-effect [causation]. The latter requires the former, but not the other way 'round.
Correlation
Correlation merely establishes a relationship but not necessarily a causation between two activities, conditions, or events. Correlation can be tested and measured from empirical obserations by mathematical analysis. The analysis can determine the degree of correlation [strong or weak, for instance] and the direction [one goes up when the other goes down]. Correlation usually occurs in a close proximity of time when circumstances affect all elements.
One commonly accepted idea in project management is that most tasks in sequence in a schedule have some degree of correlation--that is, the metrics of one task, like duration +/-, may be observed in the next, if for no other reason than they share the effects of a common project environment of policy, doctrine, values, and resource talents/capabilities in a common temporal framework. Many others, not in direct sequence, may also have some degree of correlation.
So it is common to construct a correlation matrix with one task on the vertical and the other on the horizontal of the matrix. [Take notice I do not call this a 'causation matrix']. In many projects, it's 'doctrine' to assume about 0.2 positive correlation of behavior between tasks. As a practical matter, as observed in Monte Carlo simulations, such a correlation will spread the variance a small amount. However, the purpose of the simulation is to show effects of similar behavior in the same timeframe, not to establish cause-and-effect between tasks. See Stephen Book's and Raymond Covert's presentation on page 162 of this deck.
Causation
Causation is the greater error for project managers. The true cause the true effect are correlated. But who knows what the real cause is for some observed effect?
The error PMs make is to assume that because certain conditions existed in some other successful project, then simply replicating those conditions should bring success again. MAYBE!, but maybe not.
Causation--particularly causation that repeats--is devishly hard to prove without controlled trials and careful consideration of all the circumstances. Think of all the Malcom Baldridge winners that subsequently failed in business. And, think of all the number of level 4 or 5 maturity model program offices that turn in failures. The error of false cause is especially troublesome when importing one methodology or set of practices from one situation to another. [See: Agile]. It's usually a lot more than just the practices, so don't be fooled into a false cause-and-effect story!
Assume relationships, but doubt Post Hoc, Ergo Propter Hoc.
Bookmark this on Delicious
Literally: "After this, therefore because of this":
This type of false cause occurs when the [project manager] mistakenly assumes that, because the first event preceded the second event, it must mean the first event caused the later one. Sometimes it does, but sometimes it doesn't
"Component Fallacies"
Dr. L. Kip Wheeler, Carson-Newman College
Dr. L. Kip Wheeler, Carson-Newman College
In fact, this error--false cause--is a common confusion between correlation--that is, a relationship--and cause-and-effect [causation]. The latter requires the former, but not the other way 'round.
Correlation
Correlation merely establishes a relationship but not necessarily a causation between two activities, conditions, or events. Correlation can be tested and measured from empirical obserations by mathematical analysis. The analysis can determine the degree of correlation [strong or weak, for instance] and the direction [one goes up when the other goes down]. Correlation usually occurs in a close proximity of time when circumstances affect all elements.
One commonly accepted idea in project management is that most tasks in sequence in a schedule have some degree of correlation--that is, the metrics of one task, like duration +/-, may be observed in the next, if for no other reason than they share the effects of a common project environment of policy, doctrine, values, and resource talents/capabilities in a common temporal framework. Many others, not in direct sequence, may also have some degree of correlation.
So it is common to construct a correlation matrix with one task on the vertical and the other on the horizontal of the matrix. [Take notice I do not call this a 'causation matrix']. In many projects, it's 'doctrine' to assume about 0.2 positive correlation of behavior between tasks. As a practical matter, as observed in Monte Carlo simulations, such a correlation will spread the variance a small amount. However, the purpose of the simulation is to show effects of similar behavior in the same timeframe, not to establish cause-and-effect between tasks. See Stephen Book's and Raymond Covert's presentation on page 162 of this deck.
Causation
Causation is the greater error for project managers. The true cause the true effect are correlated. But who knows what the real cause is for some observed effect?
The error PMs make is to assume that because certain conditions existed in some other successful project, then simply replicating those conditions should bring success again. MAYBE!, but maybe not.
Causation--particularly causation that repeats--is devishly hard to prove without controlled trials and careful consideration of all the circumstances. Think of all the Malcom Baldridge winners that subsequently failed in business. And, think of all the number of level 4 or 5 maturity model program offices that turn in failures. The error of false cause is especially troublesome when importing one methodology or set of practices from one situation to another. [See: Agile]. It's usually a lot more than just the practices, so don't be fooled into a false cause-and-effect story!
Assume relationships, but doubt Post Hoc, Ergo Propter Hoc.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Saturday, October 16, 2010
About triangles
Looking for those formulas that describe the Triangular Distribution, and some practical advice for Project Managers?
Try these two sites:
Formulas: a good explanation of the relevant formulas for Triangular distribution
Application advice: a couple of good points about estimating with references to others, like Glen Alleman and Steve McConnell who've written good advice on estimating with three points--think in terms of percentiles, not actual outcome values--and other foibles of estimating.
Bookmark this on Delicious
Try these two sites:
Formulas: a good explanation of the relevant formulas for Triangular distribution
Application advice: a couple of good points about estimating with references to others, like Glen Alleman and Steve McConnell who've written good advice on estimating with three points--think in terms of percentiles, not actual outcome values--and other foibles of estimating.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Thursday, October 14, 2010
The Change Curve
I ran into a blog item on change the other day, at a blog site called Rule of Thumb.
The posting entitled "The Change Curve", depicts a project management adaption of the change model proposed by Elisabeth Kubler-Ross in her book "On Death and Dying" when she described the "Five Stages of Grief"
Rule of Thumb proposes this model:
•Satisfaction: Example – “I'm happy as I am.”
•Denial: Example – “This isn’t relevant to my work.”
•Resistance: Example – “I’m not having this.”
•Exploration: Example – “Could this work for me?”
•Hope: Example – “I can see how I make this work for me.”
•Commitment: Example – “This works for me and my colleagues.”
And, this figure accompanies the posting. It illustrates the familar "dip" that occurs after change before the positive affects of change go into effect. However, it's annotated with the model ideas [given above].
So, there's not a lot new here, but as always, sometimes rearranging the deck chairs provides new insight.
Bookmark this on Delicious
The posting entitled "The Change Curve", depicts a project management adaption of the change model proposed by Elisabeth Kubler-Ross in her book "On Death and Dying" when she described the "Five Stages of Grief"
Rule of Thumb proposes this model:
•Satisfaction: Example – “I'm happy as I am.”
•Denial: Example – “This isn’t relevant to my work.”
•Resistance: Example – “I’m not having this.”
•Exploration: Example – “Could this work for me?”
•Hope: Example – “I can see how I make this work for me.”
•Commitment: Example – “This works for me and my colleagues.”
And, this figure accompanies the posting. It illustrates the familar "dip" that occurs after change before the positive affects of change go into effect. However, it's annotated with the model ideas [given above].
So, there's not a lot new here, but as always, sometimes rearranging the deck chairs provides new insight.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Tuesday, October 12, 2010
Decoupling for threats
Here's another musing on SWOT. If you missed my earlier missive, click here.
"Threats", as given in most explanations of SWOT, are future, probabilistic, external events or conditions--in other words, risks--that could stall, cancel, or redirect project activities.
And, given this explanation, what remedy is available internally to the project? [We'll stimulate to situational awareness that should always be in effect, and could provide an opportunity to work mitigations in the external community]
The best remedy comes right out of system engineering: loosen the coupling among WBS elements, especially final deliverables, as much as possible. That way, if lightening strikes one aspect of the project, the other workpackages continue onward.
If you are a sailboat guy, it means every sail should have rip-stop seams that 'decouple' one segment of the sail from another. If one segment blows out, the whole sail is not lost if there are rip-stop seams.
There are other examples: firewalls, and diversified investments to name two more
So, how do you know if you've got loose coupling in the WBS, and how would you measure it? The system engineering measures are sensitivity and correlation. And for risk managers, there are measures of diversification, statistical independence, lack of a Bayes effect between outputs.
Sensitivity is a measure of the intensity of impact--or intensity of reaction--on one element caused by another. High sensitivity means a strong reaction to a stimulus.
Correlation is a measure of the coupling, or transmittance, of the impact from one element to another--in other words, it's the 'resistance' of one element to another. Low correlation means a high resistance to the transmittance of effects from one to another WBS element.
Diversification is a practice that means: "don't put all your eggs in one basket....have multiple baskets that are independent of each other". One basket gets damaged, the others don't. For risk managers, this is detectable in a Monte Carlo simulation: if the variance--meaning the statistic called 'variance'--of the output seems to go up and down with the number of elements in the simulation, then there is good diversification and statistical independence.
We explained Bayes in other musings. It simply means that if one project probabilistic phenomenom affects the probability of another, there is a Bayes coupling of probabilities from one to the other. There are ways to measure the Bayes affects, and most risk managers are aware of how to do it.
Have someone check out your WBS: you might be able to avoid a lightening strike!
Bookmark this on Delicious
"Threats", as given in most explanations of SWOT, are future, probabilistic, external events or conditions--in other words, risks--that could stall, cancel, or redirect project activities.
And, given this explanation, what remedy is available internally to the project? [We'll stimulate to situational awareness that should always be in effect, and could provide an opportunity to work mitigations in the external community]
The best remedy comes right out of system engineering: loosen the coupling among WBS elements, especially final deliverables, as much as possible. That way, if lightening strikes one aspect of the project, the other workpackages continue onward.
If you are a sailboat guy, it means every sail should have rip-stop seams that 'decouple' one segment of the sail from another. If one segment blows out, the whole sail is not lost if there are rip-stop seams.
There are other examples: firewalls, and diversified investments to name two more
So, how do you know if you've got loose coupling in the WBS, and how would you measure it? The system engineering measures are sensitivity and correlation. And for risk managers, there are measures of diversification, statistical independence, lack of a Bayes effect between outputs.
Sensitivity is a measure of the intensity of impact--or intensity of reaction--on one element caused by another. High sensitivity means a strong reaction to a stimulus.
Correlation is a measure of the coupling, or transmittance, of the impact from one element to another--in other words, it's the 'resistance' of one element to another. Low correlation means a high resistance to the transmittance of effects from one to another WBS element.
Diversification is a practice that means: "don't put all your eggs in one basket....have multiple baskets that are independent of each other". One basket gets damaged, the others don't. For risk managers, this is detectable in a Monte Carlo simulation: if the variance--meaning the statistic called 'variance'--of the output seems to go up and down with the number of elements in the simulation, then there is good diversification and statistical independence.
We explained Bayes in other musings. It simply means that if one project probabilistic phenomenom affects the probability of another, there is a Bayes coupling of probabilities from one to the other. There are ways to measure the Bayes affects, and most risk managers are aware of how to do it.
Have someone check out your WBS: you might be able to avoid a lightening strike!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Sunday, October 10, 2010
Strength-Weakness-Opportunity-Threat
"Strength-Weakness-Opportunity-Threat": SWOT. We've all heard and read the words a hundred times.
In a little communication with a student the other day, as instructor I was offered these risk events as examples of things that go bump in a project. The student asked for help with the SWOT categories:
So, here's the way I responded:
Weakness in project plan or execution: 1), 3), 4)
Threat from external events not under project control: 2), 5), 6)
Without more information, maybe 1) and 5) go together, but it sounded like the cables were a provided item by another contractor or authority
There's not much to do 2), but maybe a better 360-situational awareness would have afforded the opportunity to get somebody going on mitigating 5) and 6). And of course, the program manager is on the hook for mitigating a weak plan as evidenced in 1), 3), 4).
Summary: except for 2), the program manager had some responsibility on the other five, even though some threats were out of the project's control.
Bookmark this on Delicious
In a little communication with a student the other day, as instructor I was offered these risk events as examples of things that go bump in a project. The student asked for help with the SWOT categories:
1) Last minute been advised network cables aren’t functioning at new site, when I have teams sitting at airport to go over and complete migration
2) Train strike in UK during Migration
3) Employer releases SME shortly before implementation.
4) Employer pulled funding for travel for implementation
5) Network lines delayed for months
6) Traders and Liquidity providers not signing off on legal agreements.
So, here's the way I responded:
Weakness in project plan or execution: 1), 3), 4)
Threat from external events not under project control: 2), 5), 6)
Without more information, maybe 1) and 5) go together, but it sounded like the cables were a provided item by another contractor or authority
There's not much to do 2), but maybe a better 360-situational awareness would have afforded the opportunity to get somebody going on mitigating 5) and 6). And of course, the program manager is on the hook for mitigating a weak plan as evidenced in 1), 3), 4).
Summary: except for 2), the program manager had some responsibility on the other five, even though some threats were out of the project's control.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Friday, October 8, 2010
Output vs Outcome
It's a remarkably simple idea, but a friend of mine reminded me the other day that output and outcome are not the same, particularly in the projects business.
"Output" is another word for deliverables, and we need not dwell more on the definition. Just refer to any manual on project management
"Outcome", on the other hand, is impact that deliverables have on the intended beneficiary. "Outcome" is another way of saying benefit; "outcome" is another way of saying what was the value-add of the project to the enterprise that hosted it or the customer/user community to which its deliverables were targeted.
This is not a difference without a distinction. Many successful outputs beget unsuccessful outcomes: just go back to the Apple Newton to see a product that worked but was unsuccessful; or, had a "New Coke" lately?
Anyway, just a musing. Think about this the next time you work on a project charter.
Bookmark this on Delicious
"Output" is another word for deliverables, and we need not dwell more on the definition. Just refer to any manual on project management
"Outcome", on the other hand, is impact that deliverables have on the intended beneficiary. "Outcome" is another way of saying benefit; "outcome" is another way of saying what was the value-add of the project to the enterprise that hosted it or the customer/user community to which its deliverables were targeted.
This is not a difference without a distinction. Many successful outputs beget unsuccessful outcomes: just go back to the Apple Newton to see a product that worked but was unsuccessful; or, had a "New Coke" lately?
Anyway, just a musing. Think about this the next time you work on a project charter.
Are you on LinkedIn? Share this article with your network by clicking on the link.
Wednesday, October 6, 2010
Virtual meeting sin
We've all been there and know the genre well. But an article by Eilene Zimmerman on virtual meetings caught my eye with this statement:
Good grief! That's probably not news, but accountability is at the heart of successful projects, so this statement should be a heads-up to any program manager that has to depend on the virtual setting.
Ms Zimmerman, quoting an industry expert, goes on to say: "In face to face meetings people really show up, not just physically but also mentally." And this damning statement: to a 'real' meeting, "....they come to the meeting prepared..." Left unsaid: to a virtual meeting no one bothers with preparation. Preparation: what a concept!
Bookmark this on Delicious
Participants in virtual meetings often feel a lowered sense of accountability
Good grief! That's probably not news, but accountability is at the heart of successful projects, so this statement should be a heads-up to any program manager that has to depend on the virtual setting.
Ms Zimmerman, quoting an industry expert, goes on to say: "In face to face meetings people really show up, not just physically but also mentally." And this damning statement: to a 'real' meeting, "....they come to the meeting prepared..." Left unsaid: to a virtual meeting no one bothers with preparation. Preparation: what a concept!
Are you on LinkedIn? Share this article with your network by clicking on the link.
Monday, October 4, 2010
Big programs and Grand Challenges
"Grand challenges" may be over the top, but I have three books to recommend if you get a return on reading factual history about big programs. I am always looking for insight from the thinking and experience of program managers who took on the big challenge, and these three books do it for me:
"A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, still in bookstores. A truly fascinating read about how a Colonel in the Air Force managed to invent the ICBM program that brought Thor, Atlas, Titan, and Minuteman along in about 10 years. The colonel also managed to collect 4 stars. Along the way, he invented system engineering, the embedded system integration contractor concept, and the aerospace firm TRW.
"The Pentagon: A history", by Steve Vogel, the story of how a brigadier in the Army, General Brehon Somervell manages to force not only the Washington establishment, including FDR, to do his will, but also how he inspired, motivated, and drove his project team to put up the Pentagon in the nine months from July 1941 to April 1942. In any objective evaluation, this was a monumental feat of program management. Like Schriever, Somervell went on to 4 stars.
and, of course, the classic:
"Failure is Not an Option" by Gene Kranz. For risk managers, this one is an eye opener. OMG! the risks they took. Along the way, they all but invented an entirely new paradigm for risk management: Failure Mode and Effects Analysis, FMEA. General Sam Phillips, who was Schriever's Minuteman PM was tapped to be the Apollo PM. Phillips is the guy that brought 'all up' testing to Apollo from the ICBM PEO. And Phillips also went on to 4 stars and a distinguished career post NASA.
Bookmark this on Delicious
"A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, still in bookstores. A truly fascinating read about how a Colonel in the Air Force managed to invent the ICBM program that brought Thor, Atlas, Titan, and Minuteman along in about 10 years. The colonel also managed to collect 4 stars. Along the way, he invented system engineering, the embedded system integration contractor concept, and the aerospace firm TRW.
"The Pentagon: A history", by Steve Vogel, the story of how a brigadier in the Army, General Brehon Somervell manages to force not only the Washington establishment, including FDR, to do his will, but also how he inspired, motivated, and drove his project team to put up the Pentagon in the nine months from July 1941 to April 1942. In any objective evaluation, this was a monumental feat of program management. Like Schriever, Somervell went on to 4 stars.
and, of course, the classic:
"Failure is Not an Option" by Gene Kranz. For risk managers, this one is an eye opener. OMG! the risks they took. Along the way, they all but invented an entirely new paradigm for risk management: Failure Mode and Effects Analysis, FMEA. General Sam Phillips, who was Schriever's Minuteman PM was tapped to be the Apollo PM. Phillips is the guy that brought 'all up' testing to Apollo from the ICBM PEO. And Phillips also went on to 4 stars and a distinguished career post NASA.
Saturday, October 2, 2010
Musings on Judgment
No doubt you've seen this quote many times: "Good judgment comes from experience, and experience comes from bad judgment"
I ran across this corollary: "A superior Program Manager uses his/her superior judgment to avoid situations that require superior skills"
So, what is this thing called "judgement".
The FAA, our Federal Aviation Administration, thinks a lot about judgment. Here is what they say in one of their manuals:
What is the FAA's advice on improving judgment skills? Teach decision making and then follow-up with experience-building situations.
Works for me!
Bookmark this on Delicious
Are you on LinkedIn? Share this article with your network by clicking on the link.
I ran across this corollary: "A superior Program Manager uses his/her superior judgment to avoid situations that require superior skills"
So, what is this thing called "judgement".
The FAA, our Federal Aviation Administration, thinks a lot about judgment. Here is what they say in one of their manuals:
Judgment is the mental process by which [people] recognize, analyze, and evaluate information about themselves, the [project] and the external environment
What is the FAA's advice on improving judgment skills? Teach decision making and then follow-up with experience-building situations.
Works for me!
Are you on LinkedIn? Share this article with your network by clicking on the link.