We’ve posted tips about targeted communication – tailoring the message for the audience. Anthony Mersino has an excellent post from January of this year about how to write a good status report. He provides seven excellent guidelines for status reporting, and all of them around providing the message our audience cares about, as effectively as possible.
Maine Mangles Medicaid – Charges CIO
Allan Holmes, for CIO Magazine just posted a scathing and detailed autopsy of the disastrous Medicaid Claims System project run by CSNI and launched in January of 2005. Requirements elicitation failures combined with incompetent vendor selection and project mismanagement lead to a $30,000,000 oops for the state of Maine, jeopardizing its credit rating. The system failed to process 300,000 claims in the first 3 months of operations, causing many health care providers to close their doors – and presumably causing citizens of Maine to go without needed services. Maine is the only state in the union (as of April 2005) not complying with federal HIPAA regulations.
Foundation Series: Basic PERT Estimate Tutorial
PERT is a technique for providing definitive estimates of how long it will take to complete tasks. We often estimate, or scope, the amount of time it will take us to complete a task or tasks. PERT allows us to provide not only an estimate, but a measure of how good the estimate is. Good estimates are a critical element in any software planning strategy. In this post, we will present an introduction to using PERT, explain how it works and how to interpret PERT estimates.
How To Use Timeboxes for Scheduling Software Delivery
Roger had a great suggestion in the comments to our previous two-part post on scheduling requirements changes based on complexity. Roger pointed out that we had not explained what timeboxing is, but implicitly used the principles of timeboxing in our proposed process. In this post, we explain timeboxes and how they are used.
Scheduling requirements changes – part 2
This process goes against agile principles on paper, but makes teams more agile in practice. Scheduling delivery of a project is an exercise in managing complexity. Scheduling changes to the requirements on the fly is really only marginally more difficult. The key to managing changes is to set expectations with our stakeholders. By defining rational deadlines for change requests, we assure ourselves that we can manage the changes. We also demonstrate responsiveness to our stakeholders. Rational deadlines are not arbitrary deadlines nor are they unreasonable deadlines. Deadlines that vary with the complexity of the changes are rational, easy to communicate, and easy to manage.
Scheduling requirements changes – part 1
Software product success requires timely delivery. There are many factors that influence our ability to properly scope, schedule, and deliver software. When we propose changes in requirements we introduce risk to the schedule. We can set reasonable expectations for our stakeholders while maintaining a realistic work environment and schedule. In part 1 of this post we detail a requirements triage process that organizes requirements by complexity and allows us to set and meet expectations of delivery.
Definition of sunk cost
Sunk cost is an expression representing the unrecoverable amount of money that has already been placed into an ongoing investment or project. It is one of the simplest, yet most commonly misused financial measurements of a project. We’ll learn how to avoid the most common mistake in project (financial) management, and how to survive when our boss makes the mistake.
Organizing a software migration project
In an earlier post on requirements for migration projects, we defined a continuum of migration projects, ranging from completely new business processes to identical processes. In this post we will look at why companies approve identical-process migration, or duplication projects, and provide some tips on how to organize these projects.
Managing scope creep is not a zero-sum game
We’ve never had a project where we didn’t have to address scope creep. As a supplier, we prioritize loyalty and relationships above incremental profitability. Project management techniques for addressing scope creep do us a disservice by starting with the presumption that resources have to be managed in a zero-sum game (every new feature must displace an existing feature). In this post we will talk about the opportunity to strengthen the relationship with our customer as part of addressing scope creep. It is not a zero-sum game.