My older son can now drive. This adds two new worries to my life—how ancient I feel and thoughts of my son in a ditch somewhere. To mitigate the second worry, my wife and I enforce a curfew and insist my son call if he’s running late. The other night, he arrived home 20 minutes late without notice. My wife was furious that he was late. I was furious that he didn’t call.
Why didn’t my son call to say he was running late? Because, like my wife, he was focused on the schedule. He avoided facing conflict until he got home. He said, “I got home as fast as I could”—presumably breaking numerous traffic regulations along the way. My son completely missed the point. The purpose of the rules was to mitigate risk, yet his response to them was to drive recklessly.
Software engineers do this all the time. They come up with a development schedule, unexpected issues come up, and they end up being late. Instead of informing their managers of the delay, they avoid facing conflict, rush the work, sacrifice quality, and slip the schedule, all with little control or visibility. It’s the opposite of what managers should want, yet those same managers insist on following the schedule precisely. Why? Because most managers and engineers don’t distinguish between the two types of scheduling—meeting a commitment and managing risk.
Those who understand binary and those who don’t
Yes, that’s right. There are two types of scheduling and project management.
§ Meet a commitment. You made a commitment to customers or partners and you must meet it at the quality and time period promised. Period.
§ Manage risk. There is a mix of critical and desirable work. People can make bad choices. Issues can arise. You must manage risk to ensure critical work gets done.
These two approaches to scheduling and project management often get confused. Why?
§ They typically appear together. The overall project has commitments, but it is made up of smaller tasks that require risk management.
§ They both use dates. The difference is that dates for commitments are untouchable and drive everything. Dates for risk management are simply checkpoints to make sure work stays on track.
§ They both are called scheduling. Most people simply don’t know the difference.
§ Meeting commitments is the only type most people are taught. From the time kids enter school, they are exposed to inflexible due dates and commitments they must meet. When they later learn project management, it is all about Gantt charts and milestones, with some risk management thrown in as an aside.
§ Managing risk is usually self-taught and informal. A small number of people are formally taught risk management. Most of us learn it from peers in college as we juggle large workloads. Instead of completing everything on-time, we form workgroups, focus on the critical work, and minimize the damage to our grades.
This tragic lack of understanding leads to horrible decisions, poor engineering, and scheduling disasters. You need to know the difference and apply the right scheduling to the right problems. Let’s start with meeting commitments.
That’s the only thing you’re committed to
Meeting commitments is essential to working with partners, which in turn is essential to running most businesses. You can’t coordinate work across internal dependencies or external agreements without synchronizing on dates and deliverables. Because commitments cascade, you must meet them or face catastrophe.
Say your daughter’s birthday is coming and you’ve promised her a new game she wants. How would you feel if it wasn’t delivered to you when promised? There is a chain of handoffs between the developer, the manufacturer, the seller, and you that all must be met to ensure your daughter’s happiness on her birthday.
Of course, this is much easier to do for Web-based products, but the same problems come up with handoffs between teams or departments. Delivering on commitments builds trust and lasting relationships between partners. Missing commitments does the opposite. While many software projects require little or no coordination across groups, running large and mature projects typically involves meeting commitments, and thus formal project management techniques.
Eric Aside
To help them make their commitments, companies typically use inventory, buffers, and other forms of risk management for individual steps in the process. That’s the whole point. You use formal project management for meeting your high-level commitments and risk management for properly completing the individual steps in your process.
Don’t you think it’s a little risky?
Risk management is about making sure the critical work gets done properly, even in highly variable environments. Scrum is an excellent example of software development practices that focus on risk management—in particular, the risk that you won’t efficiently ship value and quality to the customer.
As I pointed out in my very first column, Dev schedules, flying pigs, and other fantasies, dev schedules and test schedules are in the risk management category. All the feature dates are checkpoints to mitigate risk. Only the small number of cross-group synchronization points (major milestones) are commitments.
What matter in risk management are focus, order, and status—not precision. Focus on what’s important, do those items in priority order, and track the status as the situation changes. Notice that hitting precise dates for tasks isn’t important, so long as you finish the critical tasks at the expected quality on time. Everything else can be cut.
That’s why you must tell your engineers the same thing I told my son, “Coming home right on time isn’t important. Telling us you aren’t coming home on time is.” You can only manage the risks if you know about them. The dates are there only to alert you when plans need to change.
Of course, you can’t slip a critical task past a commitment date (a major milestone), and my son can’t stay out past 1:00 A.M. or his license will be suspended. But curfew is well before then, as it should be, to avoid any chance of catastrophe.
Eric Aside
There are many popular risk management techniques. Here are a few handy ones for software development (many taken from prior columns):
· Hold daily stand-up meetings—15 minute meetings to talk about progress, future work, and blocking issues (called Scrums in Scrum).
· Assign a backup for all task assignments (partner less experienced folks with more experienced folks).
· Use buffers—set aside time for task fluctuations (personally, I never liked this practice; I’d rather have a well-prioritized list with no intention of completing everything).
· Under promise and over deliver—also known as setting appropriate expectations.
· Establish a fallback plan—have a plan in mind in case a risky task fails, like cutting back the feature or going back to the previous version.
· Balance risk—keep the overall risk of your project at a constant state of “scary but not terrifying” by adding and removing risk as things change. For example, if a team member has a parent fall ill, your risk has increased so you should cut a risky feature or reassign that tough task you gave a junior engineer.
You pick the one right tool
So before you start working on a schedule, stop and think about what’s on it. Is it a set of dates and deliverables you’ve committed to a partner? Or is it a set of tasks with various priorities that you need to track and avoid messing up?
In the case of my son coming home by curfew, it was a task we didn’t want him to wreck, literally. Thus, we were doing risk management and the focus needed to be on giving timely status as opposed to coming home at a precise time. Most software development tasks fit that mold. You just want your engineers to tell you promptly if they are running late so you can adjust. Precision is unnecessary and potentially counter-productive.
However, if you are running a large project with multiple teams and partnerships, then commitments and synchronization are critical at a high level. The high-level schedule is full of milestones and classic project management tools.
Just don’t confuse the high-level schedule with the low-level tasks. If you treat the low-level tasks like your high-level commitments, your engineers will take shortcuts and drive too fast. Instead of managing risk, you might cause them to crash one of your critical tasks, which in turn breaks your high-level commitments. Use the right tool for the right level. You’ll sleep better at night.
Be First to Comment