Project management? For middle school students? Yes! Start'em young.
Disclosure: Gordon Meriwether, the principal at Uriahgroup.com, is an associate of mine going back many years.
Monday, April 25, 2011
Project Management for middle schoolers
For the inquisitive and energetic 6th - 9th middle schoolers in the piedmont area of Virginia, there is an opportunity this summer to get involved in a large number of workshops, ranging from art and architecture to CSI forensics and project management, held by the Piedmont Virginia Community College.
Project management? For middle school students? Yes! Start'em young.
Disclosure: Gordon Meriwether, the principal at Uriahgroup.com, is an associate of mine going back many years.
Bookmark this on Delicious
Are you on LinkedIn? Share this article with your network by clicking on the link.
Project management? For middle school students? Yes! Start'em young.
Disclosure: Gordon Meriwether, the principal at Uriahgroup.com, is an associate of mine going back many years.
Sunday, April 24, 2011
Saturday, April 23, 2011
What science knows business doesn't do
Dan Pink has interesting talk on TED about motivation. His thesis: "if/then" rewards and incentives only work well when the task is rule based and the goal is clear. Perhaps more important, he asserts that evidence shows that such incentives actually detract from performance in cases that demand creative and other right brain congnition.
Is that your experience?
My experience is that you have to be careful what you wish for: if you incent discovery of errors in software code, for instance, then coding tends to be more sloppy and error detection goes up! The 'joke' around my shop: "I'll think I'll go out and code a new car!".
This brings up the second point: look at the counter measures. You would think performance follows the money.... it does, in many cases, but incentives are another form of work rules. Work rules are often the blinders to more creative and optimum performance.
Pink, in his presentation, says the new world order is: personal autonomy, personal mastery, and meaningful purpose. Autonomy is the opportunity for self-direction; mastery is knowing your the best at something; purpose is being part of something that is important to a larger audience.
He cites Encarta vs Wikipedia, and the personal time allowed by Google and others as the demonstration of his thesis.
Whether you agree or not, his presentation is engaging.
Bookmark this on Delicious Are you on LinkedIn? Share this article with your network by clicking on the link.
Is that your experience?
My experience is that you have to be careful what you wish for: if you incent discovery of errors in software code, for instance, then coding tends to be more sloppy and error detection goes up! The 'joke' around my shop: "I'll think I'll go out and code a new car!".
This brings up the second point: look at the counter measures. You would think performance follows the money.... it does, in many cases, but incentives are another form of work rules. Work rules are often the blinders to more creative and optimum performance.
Pink, in his presentation, says the new world order is: personal autonomy, personal mastery, and meaningful purpose. Autonomy is the opportunity for self-direction; mastery is knowing your the best at something; purpose is being part of something that is important to a larger audience.
He cites Encarta vs Wikipedia, and the personal time allowed by Google and others as the demonstration of his thesis.
Whether you agree or not, his presentation is engaging.
Thursday, April 21, 2011
Is there a case for process simplicity
Phillipe Kruchten has a thoughtful posting on software process models, the basic theme of which is 'ever more sophisticated process models haven't delivered on their promises'.
Phillipe uses this quote to make his point:
You may not agree with Kruchten's theme, but you might be swimming against the tide. Survey's about software project success and failure are essentially consistent: it's hard to have a successful software project.
Of course, success is measured three ways at least: PM success of invested resources, technical success of project deliverables, and business success of deliverables in the hands of users. There's a lot of blog discussion on the latter point: for every blockbuster like "Angry Bird", there are dozens, if not tens of dozens of techical successes that are user-acceptance failures. This is one of the points about Agile: it's not a success unless the user says it's a success. [By the way, I've not heard if Angry Bird ever paid it's investors back, or not]
It's not just software. It's any intellectual property project, whether it's writing a book, a proposal, or developing a marketing campaign. The process steps can be specified and regulated; the content of each step much less so. It's too much in the eye of the beholder.
Bookmark this on Delicious
Phillipe uses this quote to make his point:
“… perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.”
Antoine de St. Exupéry, Terre des Hommes, 1939, chap.3
You may not agree with Kruchten's theme, but you might be swimming against the tide. Survey's about software project success and failure are essentially consistent: it's hard to have a successful software project.
Of course, success is measured three ways at least: PM success of invested resources, technical success of project deliverables, and business success of deliverables in the hands of users. There's a lot of blog discussion on the latter point: for every blockbuster like "Angry Bird", there are dozens, if not tens of dozens of techical successes that are user-acceptance failures. This is one of the points about Agile: it's not a success unless the user says it's a success. [By the way, I've not heard if Angry Bird ever paid it's investors back, or not]
It's not just software. It's any intellectual property project, whether it's writing a book, a proposal, or developing a marketing campaign. The process steps can be specified and regulated; the content of each step much less so. It's too much in the eye of the beholder.
Tuesday, April 19, 2011
Off the map
Sir John Keegan is not the man I would ordinarily look to for insights about project management.
Sir John is an esteemed military historian--indeed, acclaimed by many as the best military historian of the modern age--whose 20+ histories focus on the interrelated factors of popular culture, political struggle, strategic geography, battle terrain, military culture, influencing technology, tactical maneuver, and strategic vision.
In his most recent book, "The American Civil War: a military history", he dedicates a chapter to 'generalship'.
In that chapter, about USA Major General Joseph Hooker*, Keegan reports: "... Hooker lacked the ability to make 'war on the map'", meaning Hooker "... functioned well only as long as his troops were under his eye."
And, most telling, this statement: "Once they moved beyond his field of vision, he lost the power to visualize their whereabouts".
That statement really struck a cord. I've seen this too many times in the project space: team leaders, promoted to a more strategic position, unable to manage the project "on the plan", meaning they, like general Joe, can not effectively visualize what is going on when they get beyond the 'daily stand-up' and the opportunity to manage by walking about.
My observation is that these managers can't scale their management style and leadership attributes to fit the larger scope. They are befuddled by teams that are physically distributed, projects have resources in many locations, other companies may be on the project team, and the project is accosted not only by risks afar but by the forces of politics and self-interest.
+++++++++++
Photo: US Library of Congress
*Unlike most of his contemporaries, Hooker was a West Point graduate, and so presumably was educated in the military sciences. However, to fight the Civil War, armies on both sides of the conflict raised a total of over 1000 general officers in the course of four years, starting from just a handful in the antebellum US Army of the day. Thus, most Civil War generals were accidents of circumstances, nearly none of which had any formal education in military science, the management and maneuver of large units, nor the elements of leadership.
In the US Army, all but two were either brigadiers or major generals. Until late in 1864, three years after the war began, the US had only one lieutenant general and he was desk bound in Washington as Chief of Staff. Thereafter to the end of the war, only there were only two, one of which was Supreme Commander in the field, LTG Grant. Today, there are still about 1000 flag officers in the U.S. military, though about 300 are 3 and 4 star rank.
Bookmark this on Delicious
Sir John is an esteemed military historian--indeed, acclaimed by many as the best military historian of the modern age--whose 20+ histories focus on the interrelated factors of popular culture, political struggle, strategic geography, battle terrain, military culture, influencing technology, tactical maneuver, and strategic vision.
In his most recent book, "The American Civil War: a military history", he dedicates a chapter to 'generalship'.
And, most telling, this statement: "Once they moved beyond his field of vision, he lost the power to visualize their whereabouts".
That statement really struck a cord. I've seen this too many times in the project space: team leaders, promoted to a more strategic position, unable to manage the project "on the plan", meaning they, like general Joe, can not effectively visualize what is going on when they get beyond the 'daily stand-up' and the opportunity to manage by walking about.
My observation is that these managers can't scale their management style and leadership attributes to fit the larger scope. They are befuddled by teams that are physically distributed, projects have resources in many locations, other companies may be on the project team, and the project is accosted not only by risks afar but by the forces of politics and self-interest.
+++++++++++
Photo: US Library of Congress
*Unlike most of his contemporaries, Hooker was a West Point graduate, and so presumably was educated in the military sciences. However, to fight the Civil War, armies on both sides of the conflict raised a total of over 1000 general officers in the course of four years, starting from just a handful in the antebellum US Army of the day. Thus, most Civil War generals were accidents of circumstances, nearly none of which had any formal education in military science, the management and maneuver of large units, nor the elements of leadership.
In the US Army, all but two were either brigadiers or major generals. Until late in 1864, three years after the war began, the US had only one lieutenant general and he was desk bound in Washington as Chief of Staff. Thereafter to the end of the war, only there were only two, one of which was Supreme Commander in the field, LTG Grant. Today, there are still about 1000 flag officers in the U.S. military, though about 300 are 3 and 4 star rank.
Sunday, April 17, 2011
Agile Project Management library
Looking for a 100+ articles and papers on Agile PM in a pdf download format? I wasn't, but I fell onto this site looking for a specific agile topic. A quick look down their page index shows a really wide range of topics.
I've not been through many of these, so no recommendations except this one that is a reprint from the "Communications of the ACM" from December, 2005: "Agile Project Management: Steering from the Edges"
Frankly, I like it because it is written at a post-college level, something hard to find in the Agile literature, it's a case study focusing on PM, and it has some interesting insights.
One thing I don't agree with is that it equates complex software systems and projects with 'complex adaptive systems' [CAS]. CAS is definitionally about biological systems that have the ability to change and evolve behaviour in response to stimulus. Ant colonies are the classic example. I don't buy that one. Software always works the way it is designed to work, even if it's designers don't understand the design they wrought, and users don't understand how the system reacts to input and control. There's nothing biological about software, and it certainly doesn't learn, WATSON et al not withstanding.
However, there are aspects of CAS that do apply: CAS are non-linear, and software systems can certainly be non-linear, especially when tangible system assets can't meet the demands of the intangible software. CAS are open and dynamic, responding to environment. As repects the project rather than the software deliverables, I agree that many projects that deliverable intangibles have such characteristics.
But I digress: read the paper. There are things to be learned
Bookmark this on Delicious
I've not been through many of these, so no recommendations except this one that is a reprint from the "Communications of the ACM" from December, 2005: "Agile Project Management: Steering from the Edges"
Frankly, I like it because it is written at a post-college level, something hard to find in the Agile literature, it's a case study focusing on PM, and it has some interesting insights.
One thing I don't agree with is that it equates complex software systems and projects with 'complex adaptive systems' [CAS]. CAS is definitionally about biological systems that have the ability to change and evolve behaviour in response to stimulus. Ant colonies are the classic example. I don't buy that one. Software always works the way it is designed to work, even if it's designers don't understand the design they wrought, and users don't understand how the system reacts to input and control. There's nothing biological about software, and it certainly doesn't learn, WATSON et al not withstanding.
However, there are aspects of CAS that do apply: CAS are non-linear, and software systems can certainly be non-linear, especially when tangible system assets can't meet the demands of the intangible software. CAS are open and dynamic, responding to environment. As repects the project rather than the software deliverables, I agree that many projects that deliverable intangibles have such characteristics.
But I digress: read the paper. There are things to be learned
Friday, April 15, 2011
More about decision making
Tom van Gelder, a 'down-under' from Melbourne, Australia--a sister city to my former residence in Melbourne, FL USA--has a nice post from last November on decision types in decision making.
By van Gelder's reckoning there are four major categories that can be distilled from a myriad of articles, papers, books, and pontifications about decision making.
I like his list because its short, simple, and appealing to my own personal experience:
Curiously, van Gelder does not address the risks attendant with each style. Even a cursory inspection suggests the trade offs of speed, quality, consensus and participation, and quantitative back-up.
There's no 'right' answer here. "Risk is the price we pay for opportunity": thus, risk is a component of the cost to be weighed against the benefit.
Even the intuitive decision maker, making a decision for the benefit of speed, probably has a least a fleeting sense of the risk even as all formal risk management is eschewed.
On the other had, the paralysis of risk analysis that arises because there's no real calibration of data points to drive convergence to a decision, or perhaps nearly as bad--resorting to a guess--doesn't add to the quality of the decision making either.
Conclusion: the risk management process--for which you may have defined only one in the singular RM plan--may need to become 4 processes within a risk management framework, each process tuned to the exigencies of the decision making.
Bookmark this on Delicious
By van Gelder's reckoning there are four major categories that can be distilled from a myriad of articles, papers, books, and pontifications about decision making.
I like his list because its short, simple, and appealing to my own personal experience:
Intuitive Decisions
2. Technical Decisions
- They tend to be made rapidly
- They are made by individuals deciding alone
- There is little or no conscious reflection
- There is little or no following of rules or procedures
- Usually only one option is considered
- The cognitive process is typically “recognize/act” – the decision maker recognizes the situation and immediately “knows” what an appropriate thing to do in that situation would be
Technical decisions are those made by following some well-defined technical procedure. Very often a spreadsheet or computer program plays a key role in the decision processing, and indeed sometimes the decision making can be largely or completely turned over to a computer.
3. Deliberative Decisions
4. Bureaucratic Decisions
- Involves conscious articulation and evaluation of various options and the considerations counting for and against options
- Takes anywhere from minutes to months
- May be made individually, or by a group
- Often involves discussion and debate
- Doesn’t involve computers in any important way, since the relevant considerations are usually “informal” or qualitative cannot be rigorously specified or quantified
- Is not governed by strict rules or procedures, though it is subject to various norms and conventions (usually unspoken or implicit)
- Are important/weighty/high stakes
- Are “standard” sorts of decisions for the organisation; hence they
- Are made following a codified process, involving lots of steps and rules
- Involve lots of people playing their assigned roles
- Are based on lots of information, extensively analysed
- Have detailed documentation
Curiously, van Gelder does not address the risks attendant with each style. Even a cursory inspection suggests the trade offs of speed, quality, consensus and participation, and quantitative back-up.
There's no 'right' answer here. "Risk is the price we pay for opportunity": thus, risk is a component of the cost to be weighed against the benefit.
Even the intuitive decision maker, making a decision for the benefit of speed, probably has a least a fleeting sense of the risk even as all formal risk management is eschewed.
On the other had, the paralysis of risk analysis that arises because there's no real calibration of data points to drive convergence to a decision, or perhaps nearly as bad--resorting to a guess--doesn't add to the quality of the decision making either.
Conclusion: the risk management process--for which you may have defined only one in the singular RM plan--may need to become 4 processes within a risk management framework, each process tuned to the exigencies of the decision making.
Subscribe to:
Posts (Atom)