What a wonderful post. I never could have …
Comment posted on Project Management 2.0 – a fool with a tool is still a fool by Glen B. Alleman
What a wonderful post. I never could have said this myself.
Here’s my added thoughts…
http://herdingcats.typepad.com/my_weblog/2009/09/no-fool-with-a-tool-is-still-a-fool.html
Thanks for the great words
Glen B. Alleman also commented
- My opinion some new to the agile message are on the “early adopter” part of the Moore curve. As such any criticism or assessment is seen as a challenge. Those agileist who have moved further to the right (Jefferies and Sutherland) have also moved beyond the gut reaction to criticism response and into the “let me tell you how you can improve your lot in life.”
Folks like Andrew still use extremist words – “no moral motivation,” and “our product is the nest in the world” type phrases. This was the approach in the early days of XP. I used to travel in those circles, speaking at XP and Agile conferences. I took another path for my work, but I remember completely over the top claims of how XP would save the world and put organized IT departments out of business – uh probably not.
But there remains a deep confusion about writing software for someone elses money inside a corporation that is subject to governance – both corporate and IT. And essentially writing software for your own project.
Add to that the confusion between software development and project management processes. Then add the misunderstanding about how corporation actually work. Independent of all claims that IBM has adopted agile and is a bottom up shop. I can assure you that this is not true in the way Andrew wants us to believe. I say this from direct hands on talk with my next door neighbor, the neighbors (3) up the street and former neighbors who have been transferred (IBM means I’ve Been Moved). All work for or manage large chuncks of IBM Global Services here in Boulder, Colorado.
Agile processes are certainly used as a software development process – IF you consider RUP agile. Bottom Up management has ALWAYS been a large corporation engineering development process for the simple reason there are too many people – they have to have small groups bottom up management.
But the customers of IBM GS are billion dollar firms, mega-cities, and the federal government. Strong Top Down, hierarchical, command and control management still resides at the top for governance, business development, and large scale decision making.
It would be complete nonsense to have a firm the size of IBM GS “managed” bottom up in the way Adrew wants us to accept. It just ain’t so, and he’s welcome to come to Boulder and meet the managers and take a tour to see how they run their many multi-million dollar business units.
- Matthew,
Andrew mixed project management, business management, and software development all in one post.
Aside from the unsubstaniated claims in the graphic, it’s not clear what Andrew was trying to say about PM 2.0 other than forms using the bottom-up approach are somehow better off.
But he failed to state that all those firms using bottom-up operate within a business and proejct governanace model that is top-down. By skipping over that “little detail,” the suggestion is PM 2.0 is the “next big thing” in management theory – implemented by his tool of course.
PM 2.0 has many issues, not the least of which it is not connected to the core principles of project management. At least not in Andrew’s mind.
In the end I see Andrew’s approach as a common one – confusing software development methods using agile with project management methods using “some” agile.
In the absence of a framework for governing projects and the business processes they enable, the bottom up approach – while apealing – has limited traction in a real corporation.
Recent comments by Glen B. Alleman
- Project / Task progress report – can a task be 90% done?
Dina,
This is why in the Space and Defense businesses and other US Government and large construction domains the role of “program controls” separates the “doing” of the work from the “reporting” of the progress of the work. The Program Planning and Controls staff also maintains the integrity of the Performance Measurement Baseline (PMB), which is a time phased description of the cost, schedule and technical performance.Here’s some introductory background
http://herdingcats.typepad.com/my_weblog/2009/12/why-the-performance-measurement-baseline-is-the-basis-of-project-success.html - Project / Task progress report – can a task be 90% done?
The Earned Value System Descriptions used by US Defense and Space contractors defines an apportioned milestone measurement approach where predefined percentages complete can be used instead of 0/100.It is important that the apportioned milestones be “predefined” before the work is started. But the majority of “activities” inside a Work Package are measured as 0/100.
Another little known fact for the space and defense business is that all Work packages can only cross one accounting period. This means the WP is limited to 60 calendar days or 45 (or so) work days.
The key here – no matter how you decide to measure PHYSICAL PERCENT COMPLETE (and it has to be physical) is the answer the question “how long are you willing to wait to find out you’re late?” Then set the measurement points accordingly.
On large NASA programs the answer to that is One (1) Week! We do weekly earned value every Thursday with the Control Account Managers. Then a mid-month “flash report” is sent to NASA and the standard month end 533M report. So twice a month a formal assessment of ETC and EAC is done around a weekly assessment of physical progress.
This seem;s like a lot of work and it is. But the launch date is booked for mid November 2014 and there are billions of $’s of sunk cost that must be recovered with the successful launch.
For IT projects, I’ve seen behaviors that would cause contract cancellation in NASA.
- The Critical Path does not tell you everything you need to know about your Project’s constraints
This is why DID 81650 in the US Federal procurement domains mandates Monte Carlo Simulation.There is a vast amount of information regarding the issues with CP, but it is still a starting point for assessing the risks in the schedule.
- Projects failure rate – the conventional wisdom is wrong!
The fundamental issue with every one of these surveys is none define the sample space from which they were drawn. This is a common error with those unfamiliar with the guidance of statistical sampling. They send out a survey, collect the response, make some kind of adjust for those not responding.In fact the proper way is to identify who they should send the surveys to. This is a population sampling design issue.
Never believe survey results from consulting firms selling their services.
Never believe survey results in the absence of the raw data that can be confirmed independent of the survey provider.
Never believe survey results that do not have margin of errors associated with the numbers. - Monte Carlo Simulation for Dummies
Shim,Great overview. Just a couple of details.
1. The five tasks you describe have to be in series for the math to work. In series, the 90% confidence level must also have a level probability distribution, so the 90% has a 10% uncertainty.
2. The term “confidence” should be replaced with “variability.” Confidence is a scalar measure that does not describe the underlying statistical behavior of the task duration. This variability is described by the means and standard deviation of the probability distribution function – the shape of the statistical function that generates the random variables of the duration.
3. The PERT approach not only assumes independence, more importantly the standard deviation is predefined and the distribution is symmetric. Neither of which are true in practice.
4. The actual phrase for the probability of completion is “there is an 80% confidence of completing on or before at date.” Since the PDF shown in the example is a cumulative distribution function. What it says – in the sampling population, 80% of the random completion dates finish on or before a date.
5. The 3 point samples can be used for the Monte Carlo Simulations as well. The MCS can also used a Most Likely (the mode) and the statistical upper and lower limit for a specific probability distribution function (pdf). The triangle distribution is a common one for projects that don’t have historical information.
powered by SEO Super Comments
Related posts:
What a wonderful post. I never could have said this myself.
Here’s my added thoughts…
http://herdingcats.typepad.com/my_weblog/2009/09/no-fool-with-a-tool-is-still-a-fool.html
Thanks for the great words
Cheers mate, thanks.
Shim,
I have to disagree with you. Although you do have some valuable points in your post, I think you missed one important thought: agile software development is taken as an example of a bottom-up management approach. We all know that project management is not only about software development. There are lots of other industries that run projects that have to be managed. I’ve read Andrew’s posts and also checked out his slideshare presentation and I got the idea that when he says “agile” he means “agile organization” and “enterprise agility” and not agile software development. There’s a huge difference here.
Matthew,
Andrew mixed project management, business management, and software development all in one post.
Aside from the unsubstaniated claims in the graphic, it’s not clear what Andrew was trying to say about PM 2.0 other than forms using the bottom-up approach are somehow better off.
But he failed to state that all those firms using bottom-up operate within a business and proejct governanace model that is top-down. By skipping over that “little detail,” the suggestion is PM 2.0 is the “next big thing” in management theory – implemented by his tool of course.
PM 2.0 has many issues, not the least of which it is not connected to the core principles of project management. At least not in Andrew’s mind.
In the end I see Andrew’s approach as a common one – confusing software development methods using agile with project management methods using “some” agile.
In the absence of a framework for governing projects and the business processes they enable, the bottom up approach – while apealing – has limited traction in a real corporation.
Thanks Matthew.
I’ve gone back to Andrew’s to double check my understanding of his stated points. Andrew is quite explicit in his view that “The idea of constant interaction and collaboration between managers, team members and stakeholders is not new, however. Here I want to write a few words about the origins of this idea, which later became the background for Project Management 2.0.” He then, in the very next paragraph, goes on to say that “The idea of constant dialogue in project management surfaced in 2001 as one of the principles of so-called agile software development and is described in the Agile Manifesto. According to evangelists of agile methods, cooperation is crucial for the success of a project.” This is clearly saying that the underlying foundation of the PM 2.0 concept has already been conceived as part of the Agile Manifeso.
Cheers, Shim
Glen, not sure why, but there seems to be some sensitivity amongst Agile proponents for anything that might sound as criticizing the Agile concept. What we are saying here, however, has got nothing to do with Agile and is rather a statement of concern regarding a possible confusion between the what project management is, compared with tool and techniques that project managers might use as part of their job. Agile is a great methodology, and using it in the right environment and under the correct circumstances can bring in the expected benefits.
My opinion some new to the agile message are on the “early adopter” part of the Moore curve. As such any criticism or assessment is seen as a challenge. Those agileist who have moved further to the right (Jefferies and Sutherland) have also moved beyond the gut reaction to criticism response and into the “let me tell you how you can improve your lot in life.”
Folks like Andrew still use extremist words – “no moral motivation,” and “our product is the nest in the world” type phrases. This was the approach in the early days of XP. I used to travel in those circles, speaking at XP and Agile conferences. I took another path for my work, but I remember completely over the top claims of how XP would save the world and put organized IT departments out of business – uh probably not.
But there remains a deep confusion about writing software for someone elses money inside a corporation that is subject to governance – both corporate and IT. And essentially writing software for your own project.
Add to that the confusion between software development and project management processes. Then add the misunderstanding about how corporation actually work. Independent of all claims that IBM has adopted agile and is a bottom up shop. I can assure you that this is not true in the way Andrew wants us to believe. I say this from direct hands on talk with my next door neighbor, the neighbors (3) up the street and former neighbors who have been transferred (IBM means I’ve Been Moved). All work for or manage large chuncks of IBM Global Services here in Boulder, Colorado.
Agile processes are certainly used as a software development process – IF you consider RUP agile. Bottom Up management has ALWAYS been a large corporation engineering development process for the simple reason there are too many people – they have to have small groups bottom up management.
But the customers of IBM GS are billion dollar firms, mega-cities, and the federal government. Strong Top Down, hierarchical, command and control management still resides at the top for governance, business development, and large scale decision making.
It would be complete nonsense to have a firm the size of IBM GS “managed” bottom up in the way Adrew wants us to accept. It just ain’t so, and he’s welcome to come to Boulder and meet the managers and take a tour to see how they run their many multi-million dollar business units.
[...] see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. [...]
RT @shim_marom: Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR
RT Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR I love it! This applies to test automation as well!
RT: @agilenature: RT @shim_marom: Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR Me ecntanta la frase!
RT @agilenature: RT @shim_marom: Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR
RT @lanettecream RT Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR I love it! This applies to test
RT @shim_marom: RT @lanettecream RT Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR I love it! This a …
Shim,
I have to disagree with you. Although you do have some valuable points in your post, I think you missed one important thought: agile software development is taken as an example of a bottom-up management approach. We all know that project management is not only about software development. There are lots of other industries that run projects that have to be managed. I've read Andrew's posts and also checked out his slideshare presentation and I got the idea that when he says “agile” he means “agile organization” and “enterprise agility” and not agile software development. There's a huge difference here.
Great point, especially “A fool with a tool is still a fool.” But regarding tools, such as collaboration, they are both an opportunity and a necessity. For example, not long ago, multi-national teams employing a lot of offshoring did not exist. However, with the internet infrastructure and the collaboration tools that have evolved with it, new opportunities have arisen to become more effective. Maintaining competitiveness has also made such tools a necessity in many situtions. But the basics of project management still remain the same, and “A fool with a tool is still a fool.” remains a valid statement.
Thanks John.
Yes, latest Web 2.0 collaboration technology has provided a plethora of tools all aimed at making our lives easier. I hope (although not entirely convinced) that organizations will use common sense in determining which tools they allow / encourage and which ones that stir away from as some of these tools are good and some are time wasters. I’ve seen a number of blog posts promoting so-called social networking tools as project management enablers. I use social networking personally but would not encourage allowing these tools in the workplace as they add no value what-so-ever to the well being or productivity of the organization. Technology should be used when appropriate and not just for the sake of using it as it is only the means to an end and not an end in itself.
My Recommendations
Recent Posts
Recent Comments
Categories
Copyright © 2010 quantmleap ® All Rights Reserved | Powered by WordPress | Infinity Remix theme by Tips and Tricks HQ
Log in | Comments (RSS) | Entries (RSS)