Tag Archives: Strategic Analysis

Thus I Refute #NoEstimates

Posted on by
Reply

In a recent blog post, Woody Zuill – fellow blogger, fellow middle-aged software guy, and fellow banjo picker – gave his personal definition of the #NoEstimates Twitter hash tag that has been the venue for a lot of online discussion lately.

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development.  That is, ways to make decisions with “No Estimates”.

Woody and several others in the Twitterverse and Blogosphere have been advocating for making decisions (more accurately, applying constraints) that don’t require estimates, in order to eliminate the need to make other decisions that would require estimates.  Neil Killick recently posted an explanation of how to do Scrum without estimates, including this example:

Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint).

Implicit in the example is that once time and schedule are fixed, only the scope is flexible.  While this would certainly make things easier for the software developers, it adds complexity for everyone else.  To explore Neil’s example, let’s assume that the Australian Open app is a public-facing, self-service web site where the general public can buy tickets, see the daily results, read and comment on the news coverage of the event, and possibly follow links to the personal web sites of the players.  But what else is involved in serving the public audience interested in the Open?  I ask because, in the real world, not all members of the public are going to use that web site.

Presumably, the Open will have a call center to handle inquiries and purchases from those who don’t find or can’t access the web site.  They may also have an interactive voice response (IVR) system to support certain kinds of queries and possibly even ticket purchases.  So the Decision Makers will want to make the Australian Open app fit into this operational framework, providing capabilities and services for the public that supplement or complement each other.  To do this, they need to have a firm list of capabilities (or scope) defined for each of the three projects – Call Center, IVR system, and web app.  That way, the can staff the Call Center appropriately, work with the marketers to provide instructions to people in directing them to the IVR or app, and otherwise direct user traffic.  But if the Call Center folks and IVR configuration team don’t know until three days before the Open starts what functionality the web app will have, that doesn’t leave them much time to react, do they?

Of course, it might be wise for the Decision Makers to conduct a “buy or build” analysis, since large events are quite common and have spawned a number of service offerings, including Software as a Service.  But in order to conduct that analysis, they would need a firm feature / capabilities list and cost estimate for the internal development effort, to compare it with the vendor offerings.  And if all the internal developers can commit to is cost and schedule, it makes comparisons impossible.

A group of frogs who live at the bottom of a well are enjoying their nightly chorus of croaking, when one of them announces that he is studying astronomy.  When he gets a quizzical look from one of his comrades, he explains that it is the study of the sky.  “You know: that little round thing at the top of the well.”

Complexity will persist in the face of all attempts to reduce it through simplifying assumptions.  Few modern business problems are simple enough to reduce to a small number of decisions, which then drive all other activity.  Apples falling out of trees are fine for explaining gravity to school children, but celestial mechanics has to contemplate multiple bodies.  Similarly, modern business problems are not simply about software.  And that is why we should devote our energies to improving the quality of our software development estimating methodologies, rather than advocating adoption of simplifying assumptions that don’t reflect a holistic view of the operating environment.

A Period of Transition

Posted on by
Reply

It’s December 30, according to the widget in the lower right corner of my screen.  Over the last week or so, I’ve seen dozens of lists, retrospectives, reviews of what was accomplished (or not), and more than a few assessments.  I’ve even seen some predictions for 2013 and beyond, in addition to the usual batch of resolutions, dubious (and earnest) plans, and vows to do something different; or at least, do the same things, differently.  But I tend to view this little window of time not as an end or beginning, but as a period of transition.

No matter what deal President Obama and Congress eventually agree to, I think we can safely assume that the special tax treatment for qualified dividends will go away.  Will this reduce the attractiveness of dividends for corporate America, and free up more cash flow for capital investment?  Maybe; but in any case, the last few lean years have seen a lot of deferred maintenance.  A lot companies are looking at the cost of annual support fees, and re-thinking their commitment to premises-based software.  I suspect we’ll see rapid growth in the trend of replacing enterprise applications with Software-as-a-Service.  But I suspect we’ll also see a lot of upgrades to aging ERP applications, too.  IT project managers will have a lot of work to do in these two areas – just a quick look at the postings on Dice will confirm that the scramble for talent has already begun.

On another level, PMI has now started the roll-out of the fifth edition of the PMBOK, as well as the third editions of the Standards for Program Management and Portfolio Management.  A lot of organizations that have embraced these documents as sources for the core of their project management and governance processes have some decisions to make.  What shall we change?  What shall we retain?  How shall we manage the transition?  There will likely be a number of blog posts, articles, white papers, and even books on the subject, and a lot of consultants will find work guiding organizations and their PMO’s through the process.

And let’s not forget the mega-trends: climate change, the growing scarcity of potable water, and food shortages.  If you were disappointed that “instead of a Mars colony, we got Facebook,” take heart.  We’re about to enter a period when much of our most valuable innovation will be driven by human survival.  From wind power to crop management to natural disaster mitigation, the future is going to be built with information.  There will be a lot of opportunities for information technology to contribute, and for IT project managers to make a difference.

Will things be different?  Sure – they always have been.  And as drivers of change, we’ll have a role in the transition.  Maybe even a critical role.  For some of us, a decisive role.  So, if you’re ready to lead the next round of changes, this will be a tremendous opportunity for you.  Because every period of transition needs leaders and managers who can be a calming influence.  And be sure to take good notes, because the projects you’ll lead over the next few quarters will likely be the most compelling part of your next resume.

New PM Articles for the Week of December 26 – January 1

Posted on by
Reply

New project management articles published on the web during the week of December 26, 2011 through January 1, 2012.  We read all of this stuff so you don’t have to!  Recommended:

  • Mike Beard looks at “deciding how to decide.”
  • Joel Bancroft-Connors does a retrospective on taking the PMI-ACP exam, while he waits for the test results.
  • Don Gray looks at an organization not doing Scrum, no matter what they call it.
  • Michael O’Brochta and Curt Finch tell of Michael’s experience building and running a strategic-level PMO for the CIA, meshing execution and project governance.
  • Dmitri Ivanenko believes that we can boost our productivity by better naming the tasks we assign to ourselves – describing actions, rather than results.
  • Craig Strong thinks we need to challenge everything.  “Do we really need to do that?”  Well, that’s one way to put your inner child to work …
  • Joel Semeniuk offers five Agile project management techniques you can start using today.  First: “Don’t call it Agile.”
  • Brad Egeland suggests some interview questions for prospective project clients.
  • Starting a website project?  Bert Heymans shares a list of questions to elicit the high level requirements.
  • Terence Metz illustrates his technique for identifying stakeholders “by examining the way that they interact with the organization in providing or receiving services or benefits.”
  • Roger Chou looks at project portfolio management as a mechanism for business planning, or as he puts it, “business mapping.”
  • Bas de Baar greets the New Year by reminiscing about the Millenium Bug.
  • Stephen Pritchard considers the outlook for IT managers in the UK during the coming year.

Enjoy!