This is Glen B. Alleman's Typepad Profile.
Join Typepad and start following Glen B. Alleman's activity
Join Now!
Already a member? Sign In
Glen B. Alleman
Boulder, Colorado
Performance-Based Project Management®
Interests: Earned Value, Risk, Cost, Program Performance, Integrated Master Plan, Integrated Master Schedule.
Recent Activity
Writing software for money is a Closed Loop Control System. The Reference is our needed performance - cost, schedule, and techncial - to acheive the projects goals. These goals include providing the needed business value, at the needed cost, on... Continue reading
Posted 4 days ago at Herding Cats
I love it when there is a post about Myths and Half-Truths, that is itself full of Myths and Half Truths. Orginal text in Italics, the Myth Busted and Half Truth turned into actual Truth beow each Myth: If your... Continue reading
Posted 5 days ago at Herding Cats
Conveniently Unburdened by Evidence - Kate Beckett to Richard Castle When we hear a conjecture about a topic that skips over principles of business, the economics of decision making, or the mathematics of probabilistic and statistical modeling, listen to what... Continue reading
Posted Dec 10, 2014 at Herding Cats
In a recent presentation, Tim speaks further about managing in the presence of uncertainty and the application of agile in software development. Plans NEVER go right, planning in presence of uncertainty, requires - DEMANDS actually - estimating risk, uncertainties, unknowns... Continue reading
Posted Dec 9, 2014 at Herding Cats
There remains serious misunderstandings of how, why, when, and for what purpose estimates of cost, schedule and delivered capabilities are made in the development of software systems using other peoples money. There are three distinct approaches to the problem: Schedule... Continue reading
Posted Dec 7, 2014 at Herding Cats
Patrick, The original poster is a well known agile voice, the Agile Alliance's 2005 Gordon Pask Award for Contributions to Agile Practice. But these single vision statement reveal a narrow understanding of how software is developed outside their own experiences. This is rhe difference between "knowing" and "doing." In our "doing" domain if Software Intensive Systems (SIS) and guidance like Estimating Software Intensive Systems Engineering SIS In these domains, tools are a critical success factor, starting with the Systems Engineering design tool, one of the ones we use is and at NASA. But the notion that complex systems and resulting complexity in the design, development, and testing can some how be tested for complexity by having the system's work be contained on a "board" (physical sticky notes on the wall), begs the question - "you ever work a program where that suggeston would be laughable?" Probably not.
1 reply
Orion launched today and recovery after two orbits. The test of the launch system, Pad Abort system, and Heat Shield were the main purposes of the flight. I worked the proposal - after coming off the winning proposal for Hubble... Continue reading
Posted Dec 6, 2014 at Herding Cats
There is a popular notion that requirements stability is difficult to acheive, because customers don't know what they want. Ignoring for the moment that requirements instability is the root cause of Death March project and let's pretend requirements stability is... Continue reading
Posted Dec 5, 2014 at Herding Cats
When we hear I'm a developer is that the same as I'm a Software Engineer. What does it mean to be a software engineering versus a developer of sofwtare? Peter Denning's review of he book A Whole New Engineer in... Continue reading
Posted Dec 4, 2014 at Herding Cats
Working in Phoenix this week on a Program Management Office deployment for a government agency providing public health services. We're installing processes and training staff on the notion of Measures of Success (a term I had not heard before), that... Continue reading
Posted Dec 3, 2014 at Herding Cats
Plans are only good intentions unless they immediately degenerate into hard work. - Peter F. Drucker Continue reading
Posted Dec 2, 2014 at Herding Cats
Systems Engineering has two components System - a set of interrelated components working together toward some common objective. Engineering - the application of scientific principles to practical ends; as the design, construction and operation of efficient and economical structures, equipment,... Continue reading
Posted Nov 30, 2014 at Herding Cats
There is an abundance of estimating guidance to counter the abundance of ill-informed notions about estimating. Here's some we use on our programs, Handbook of Software Cost Estimating, JPL D-26303 Rev 0 Software Cost Estimation Using A Decision Graph Process:... Continue reading
Posted Nov 29, 2014 at Herding Cats
Vasco Duarte posted on twitter a quote (without link) ... Bad estimation is a systematic problem, not an individual failure ... The chart below is from a much larger briefing on Essential Views needed to increase the probability of success... Continue reading
Posted Nov 28, 2014 at Herding Cats
There is much confusion in the domain of project management and especially software projects between complexity, complex, and complicated. Wikipedia definitions almost always fall short. The book on the left is the latest addition to this topic in the domain... Continue reading
Posted Nov 27, 2014 at Herding Cats
The current issue of ICEEAWorld, has an article on estimating on agile projects. Continue reading
Posted Nov 26, 2014 at Herding Cats
To build a credible estimate for any project, in any domain, to produce a solution to any problem, we need to start with a few core ideas. Gather historical data. Unless you're inventing new physics, it is very unlikely what... Continue reading
Posted Nov 25, 2014 at Herding Cats
Rally Software is a local firm providing tools for the management of agile project. Project Managers provide the glue for all human endeavors involving complex work processes. Rally has those tools as do many others. Rally also has message that... Continue reading
Posted Nov 25, 2014 at Herding Cats
So this is yet another example of "knowing" versus "doing" It'd be unlikely that "knowing" that plans change and acting accordingly is not the norm, behaving in that way seems to somehow be harder outside of the domains where "Program Planning and Controls" is the norm, even for agile software intensive systems
Toggle Commented Nov 24, 2014 on Mike Cohn's Agile Quotes at Herding Cats
1 reply
No credible planning process "sticks to it too rigidly." The "plan" is actually the process of executing the strategy. So the "plan" is an object that is adjusted. The confusion comes when some see the "plan" as a throw away "object." It is not. The "plan" is the representation of the current strategy for success. I can look at the "plan," touch it, put it on the wall, send it to the participants, so they know what work must be done to "increase the probability of success." The "plan" is a "thing" developed from the strategy. Here's how we apply those concepts and where the capabilities that the plan describes come from That original phrase is often misused in the absence of guidance on how to plan, and how to execute from the plan. It becomes a platitude to escape answering the question "what does done look like."
Toggle Commented Nov 24, 2014 on Mike Cohn's Agile Quotes at Herding Cats
1 reply
Mike Cohn of Mountain Goat Software has a collection of 101 Agile Quotes. There are few I have heart burn with, but the vast majority are right on. Some of my favorite: Planning is everything, plans are nothing - Field... Continue reading
Posted Nov 24, 2014 at Herding Cats
When we read on a blog post that estimates are not meaningful unless you are doing very trivial work, † I wonder if the poster has worked on any non-trivial software domain. Places like GPS OCX, SAP consolidation, Manned Space... Continue reading
Posted Nov 23, 2014 at Herding Cats
I n a recent email exchange, the paper by Todd Little showing projects that exceeded their estimates was used as an example for how porrly we estimate, and ultimately one of the reasons to adopt the #NoEstimates paradigm of making... Continue reading
Posted Nov 22, 2014 at Herding Cats
On a twitter discussions and email exchanges there is a notion of populist books versus technical books used to address issues and problems encountered in our project management domains. My recent book Performance-Based Project Management® is a populist book. There... Continue reading
Posted Nov 20, 2014 at Herding Cats
Mike, Thanks for the follow as always. The notion that ideas can live in the absence of testing appears to be troubling for some. From our common experience in the physics world, we both know the feeling of standing in front of the PI (in our case a Nobel Laureate) and making a suggestion about something we know quite a bit about. Only to have him ask a simple question - "have you tested you observation and explanation of that observation against all the other possibilities that may be the cause of what you have seen?" No, please do, then come back. As experimentalist, we be asked to stop by the theorist student's office as well just to confirm we actually had the underlying principles well in hand before proceeding to confirm what we saw, which could possibly have been "statistical noise."
Toggle Commented Nov 20, 2014 on Quote of the Day at Herding Cats
1 reply