Journyx Project Management Blog

In this article, I will try to tell you a way you can tackle one aspect of a project—software estimation. I will tell you how I estimate projects and the geometry involved, and if unfettered by poorly judged external forces this way leads me to a successful delivery. But, the most important thing is that these are general guidelines and there is simply no substitute for individuals and teams that can succeed in their own way. Individuals and individual teams must be permitted to use their own judgment, for there is no more desirable outcome than a delivered and well received product. (Until software becomes an assembly-line process and by then, God willing, I’ll be horizontal.)

Geometry

Geometry applied in the context of software development project estimation refers to the size, shape, and relationships among all of the elements of a software project, including those practices whose direct result are tangibles and those time slots that are essentially intangible but necessary in some way. Many estimators get some of the tangible parts of estimation correct, but it is all of the intangible aspects that are often overlooked and result in delays, disappointments, and undelivered software.

Tangible elements (often called deliverables) can include project plans, requirements, detailed designs, the software, and time spent testing, debugging, documenting, and launching software. Many people know about these elements and some include these elements in estimations. Sadly, some do not include all of these elements. Intangibles such as water cooler time, illness, bad requirements, wrong requirements, changed requirements, unforeseen hard bugs in your code or the tool provider’s code, learning, white board time, unit tests, arguments, meetings, distractions, failed or replaced hardware, absenteeism, car accidents, sustainable productivity levels—getting in and staying in “the zone”—reading FoxNews.com, checking out research.microsoft.com and more, are all too often overlooked, dismissed, or denied. But, these are the elements as likely to happen as coding that chew away at the schedule, willingly or not, and is what is most often overlooked in a project schedule. To account for the tangibles, methodologies like RUP were invented. To account for intangibles, methodologies like XP and Scrum were invented. But, again there is no substitute for having people who have demonstrated an ability to deliver.

Tip: Software projects that succeed often have a single-minded determination and focus on the number one deliverable, the software.

Read the entire article at Developer.com.