Glen, thanks for another great slideshare. The pop-culture agile software community certainly seems more interested in selling their wares than in progressing the state of the practice in a way that stands up to scrutiny. I did not come to this conclusion lightly, as I had hung my hat on the alter that is agile for some time. I recently wrote a very short blog entry, comparing the progression of research in agile methods to integrated concurrent engineering from astro/aero. Much peer reviewed work on ICE exists, yet almost nothing exists for the agile crowd. Why not? http://hank-roark.blogspot.com/2011/03/integrated-concurrent-engineering-vs.html Cheers, Hank

Well, the slides look fine on the slideshare full site, just not embedded in the blog. Sorry for the extra comment.

Hi Glen, it looks like Slideshare did not convert slides 11-20 correctly. Cheers, Hank

Glen, I am with you in that I cannot imagine public sites like Facebook and Twitter to be the basis of the future of project management. There has been some recent work to mine databases and email and other electronic resources to determine the social networks and interactions between project participants. Different projects show different behaviours. I have seen one where the functional groups were all clearly grouped into their individual social groups, with multi-disciplinary engineers providing the bridges between the various functional groups. Another project had a core of multi-functional engineers that worked amoung themselves as one group and basically cooridinated the activities of individual specialists. I believe Gergana Bounova has been analyzing these looking for opportunities to understand various project dynamics. Cheers, Hank

Glen, I read through the presentation trying to discern the difference in risk and uncertainty. I had always considered uncertainty as a measure of the spread of possible project outcomes (standard deviation if the outcome follows a normal distribution, for example). Risk was then the probablity of having an undesirable outcome (the chance of having a negative NPV, or the chance of exceeding the projects management reserve, for example). This definition might better match with the definition of value at risk (VARG), so it might not be what you are getting at in the presentation. Is this the definition you were getting at in the presentation? Cheers, Hank

Dennis and Glen, First, let me say "Great conversation." I would like to add is that this pattern seems to repeat itself over and over in the software industry. I used the term 'industry' explictly and avoided labelling 'it' as engineering or science. The pattern that I see is that one group (in this case the Agile and Lean branch of the industry) has to disparage another branch of the industry in order to sell their wares. There is limited learning between the groups (or just enough learning to gain the next competitive advantage). This has repeated itself every decade or so in the software industry. It gets worse in that the industry rarely learns from other disciplines. Imagine if the presentation had been actually comparing state of the art to state of the art. We might have had a more balanced view of the benefits and risks of each (e.g., more iterations are better in this context, but less iteration are better if this is the situation; integrated project teams work better when X is true and functional grouping work better when Y is true). Until the software gets out of this model of being an industry this story will repeat. It makes me sad. Cheers, Hank

Glen, if you haven't seen them, I would also recommend the work on real options in engineering systems by Richard de Neufville. He has done a lot of work on valuing flexibility in uncertain situations, such to decrease programmatic risk. -- Hank

I have two guesses as to what (most) people mean when they say Agile EVM: - Their scrum burn-up chart looks a lot like those EVM charts of BCWS, ACWP, and BCWP...so we must be doing Agile EVM. - They have no idea what EVM is, so add an adjective, and redefine EVM to mean a burn up chart. Cheers, Hank

The arm chair quarter backing is exhausting. I wonder if it is just part of the game. (Putting my engineering hat on...) The politics spoken about reminds me of game theory. Everyone is playing games, trying to get the best advantage. I've certainly seen it in the commercial sector where business cases are manipulated based on the assumptions that the approver of the business makes, as well the criteria is manipulated by those governing the portfolio because they expect the team to be gaming the system. I have heard horror stories about this in government contracts. It seems, if we could better understand the objectives of the players and build a model of the game, then we just might be able to manipulate the system so that it supports more desirable behaviour. If only it were so easy. Back to my arm chair :-)

This made me LOL!! How very sad. I am so very happy we homeschool our children.

I would argue that Derek is exemplifying the fundamental attribution error: the tendency to over-value personality. In this case it may be better to look at potential system causes of the late arrival. There are many things that are in the system that could cause this to happen. Take for example the use of MS Outlook to schedule meetings: the default start and end times are on the half hour. At my organization it is not uncommon for someone to be booked back to back in a meeting with zero transition time. Now, for the meta-question: what in the system is causing Derek to promote a personality based explanation instead of considering the structure of the system as a potential cause?

Glen, I'm not sure what I can say, except I completely agree with your observation. I have a degree in Physics, but have spent much of my career doing commercial software development. With that said, I have spent much of my life working with those gray haired/no haired types you mentioned. They do things like build bridges and roads and design mission critical industrial equipment. Even more recently I have been pursuing a masters degree from a school on the Charles River and getting to spend quite a bit of time with people that take engineering systems seriously. The analytic, fact based approaches I see are largely absence in the commercial IT sector. Worse yet, people are identified as experts/masters not by their results and experience and know-how, but by management decree or some other questionable approach. The IT and "mainstream" (or is that vocal) software folks are missing a whole range of knowledge and tools by not being part of the engineering community. And I'm sure the engineering community could benefit from the experience of IT professionals (the real professionals) on design, deploying, and operating large systems of systems. Now the question is, what in the system either makes this acceptable or desirable? I can't believe it is because the IT community wants to do a bad job. I believe it is deeply root in the fact that it is easy to get IT and software to do what you want it to do without much knowledge or skill (e.g., "anyone can become a programmer"). Whereas for mechanical systems, it is hard to get system or sub-assembly to do what you want it to do with robustness. There are other barriers, like the words used between the two domains is completely different and when they use the same words they more often than not mean completely different things. In any case, I think both are missing a lot by not being connected. With all the advancements in IT and software that have been made, imagine where it might be if the software/IT folks had a more engineering-like approach (no more blue screens of death?). And I think there is quite a bit the engineering systems folks can learn from the IT professionals on designing, deploying, and operating systems of systems. It is too bad there is such chasm to cross. Cheers, Hank

Glen, I think this observation may point to the behaviour observed in IT projects: "At the core enterprise IT project lack the discipline found in heavy construction, defense and space." Construction, defense, and space programs grew their capabilities based on engineering. I rarely see engineering competencies demonstrated in IT organizations. (Thanks for the pointers. I'm afraid I'm about two dozen steps away from getting my "project manager" to understand the content. I said "probablity distribution function" during that project review and got that glazed over look you get when someone has no clue what you just said.) Cheers, Hank

Glen, thanks for the post. I sat in a project review two weeks ago where the "project manager" (loosely used term) presented a schedule and series of risks associated with the schedule (don't get me started on the quality of these risks). I enquired as to the chance of achieving the schedule. The reply was "This is the best case schedule." I nearly choked. I had to explain that we make marketing plans and budget plans based on planned completion of projects. This behaviour is beyond me, except that I just think there are a lot of people out there with the title "project manager" that don't have the basic skills to do their job. Cheers, Hank