|
|
 |
|
Risky Beginnings
How to Start Your Projects off on the Right Foot
© Esther Derby 2000-2002
This article originally appeared in STQE Nov/Dec 2000.
- 8 questions to ask before you start a project
- How to mitigate risk and get the support you need
Have you ever managed a project that went, directly, hopelessly, and irretrievably, to hell? Would you like to avoid some of the traps so your project doesn't end up there?
Projects get off track for a lot of reasons. Sometimes they get into trouble because of things we just can't anticipate at the start. Sometimes projects drift off-track as work takes longer than anticipated, or when shortcuts taken to "save time" lead to intractable problems. And sometimes the signs are right there from the start. These are the problems that are easiest to spot, yet they still bedevil many projects.
Fifteen years ago I was a first time project manager, straight out of the programming ranks. I was tenacious and a good problem solver, and my boss wanted to give me an opportunity to move up in the organization. He picked me to lead the first big project my area had done in years: a data base migration. The project involved moving data from one database management system (DBMS) to another, and replacing the existing data access routines in a large system. We were all familiar with the existing systems’ data access methods, but this was a much larger effort than the small patches and enhancements we usually worked on. We would be touching almost every module in the system, and writing programs to move data from the existing structure to a new one based on a normalized data model.
I didn't know much about project management: I'd never managed a project or led a team. But I knew the system, and I wanted to do a good job. So I took the half-page project description and target date from my boss, made a plan, and set out to manage the project. I felt good about starting this project—I believed that the problem was pretty straightforward, and that it was a good chance to prove myself.
I remember the feeling I had when I realized that my project was in trouble: that big ball of steel at the bottom of my stomach. I felt it for the first time the day my boss stopped by my desk and admonished me not to waste too much time planning and analyzing…that I'd better get the team coding if I wanted to make the date.
"But," I pointed out, "we don't have the specs done yet, so..."
"Don't waste time with that," he countered. "The specs are in the existing code. Just turn the programmers loose on it, and they'll know what to do."
That was the first inkling I had that things wouldn't go as smoothly as I imagined. And as the weeks went on, more and more problems kept cropping up. The work was taking longer than anticipated, and the customers were getting worried about the date. My team wasn't acting like a team, and I certainly didn't feel like a leader. Signs of trouble kept mounting.
- Programs we had estimated would take a week to finish were taking two or three weeks.
- Code that was turned over as "complete" wasn’t really done. Some modules were missing functions.
- We were fighting with the support team over shared resources. It always seemed as if they either needed to make emergency patches to programs we were working on, or they were booting us out of the test environment to test the emergency patches.
- Although the project was supposed to be a straightforward database migration, the customers persisted in asking us to fix existing problems and add new features.
- All those fixes and new features meant more development and more testing—with no change to the target date and no more resources to do the work.
- Our relationship with the end user had always been a little tense; now there was blatant unfriendliness.
- We weren't going to make the code freeze date, and the test manager was furious about having less time to test.
I was in over my head and I knew it. I'd started to lose sleep: most nights I'd wake up at 3AM with my mind churning over the latest crisis. I knew my boss wasn't happy about the project. He alternated between telling me how disappointed he was in me and not speaking to me at all. When I finally got called in to meet with my boss and the VP, the two of them frowned at me across the conference table. "Remember," they growled,
"you are accountable for the success of this project! You'd better pull this thing together and get it done!"
I didn't know how to respond.
It was true, the project was in a terrible mess. I'd tried my best, and somehow I felt that if I'd just tried harder, I could have made it work. I didn't realize it at the time, but trying harder wouldn't have been enough to make this assignment a success.
Looking back at this painful first project, I know that at that time I didn't have the skills to do the job—and I didn't have enough experience to see trouble staring me in the face from the get-go. My project didn't get into trouble: it
started in trouble. It didn't even stand a chance.
And my inexperience was only one of the factors that put the project at risk. My organization didn't have basic project management practices in place. We didn't create a charter to establish agreement on scope and objectives. We didn't assess and manage risk, or manage change on the project. We entered the fray armed only with a half-page description of the project objectives—but at the time that was viewed as more than adequate. We didn’t have the skills resources we needed, either—the team members were very good at trouble-shooting, support and making small enhancements, but they didn't have the front-end software development skills necessary to take on a bigger effort.
And we didn't have the infrastructure—testing environment and software configuration management—to support concurrent efforts. Not only didn't we have all the necessary project ingredients…we didn't even know we
should have these things. Let's face it: when it came to running projects, we didn't have a clue.
Here are the eight questions I wish I'd known to ask way back when, before I'd taken on a project that
looked simple but was, in reality, high risk:
1. Do the customers and the developers agree on the project objectives?
I went into the project believing that our objective was to migrate to a different DBMS—I accepted the project objective my boss gave me at face value. The customers, on the other hand, viewed it as a chance to add features and fix problems. This disconnect lead to misunderstanding and eroded my relationship with the customers. And since we had no way to assess and evaluate the impact for all the fixes and features the customer requested, almost every suggestion was added into our project because, as my boss said, "We're in that program anyway."
Project objectives need to be clearly stated and understood by all parties at the outset. If the parties don't agree, then getting that agreement needs to be your first task. Looking back, I could have checked out the customers' agreement with the stated objective as part of the project startup. I might not have gotten much help, but at least the problem would have been out in the open.
2. Has the organization done a project like this before? Does the organization have the process infrastructure to support project management?
In my case, our group hadn't done a big project for several years. And in the organization as a whole, "project manager" was a just a title; we lacked an established project management practice or training program.
In my experience, it's a big shift to go from supporting a product to doing a development project. If the organization hasn't done project work before—or done projects of this type or size before—then it's unlikely that the skills will be there. Successful projects need a way to establish objectives and scope, manage change, and keep status visible (e.g., reviews, micro-milestones, and status reporting).
Establishing new practices can take months; it's not as simple as distributing a memo during the project kickoff. And it's a tough job to build the project management infrastructure and manage a project at the same time—it adds to complexity and increases the burden for an inexperienced project manager.
3. Has the team done this kind of work before? Do the team members have the necessary skills?
Like me, the team members on my project were great troubleshooters. They knew the technology and the system—but they had little experience doing requirements, analysis, or design.
Sometimes you can get around inexperience if there's time for training and coaching. But don't expect a one-week training course to provide the level of skill needed. Mastering skills takes coaching and practice, too. If the team isn't starting with the necessary skills, you’ll have to build in time for training—and then build the learning curve into the schedule. It's hard to predict what a learning curve will be, but if it's acknowledged as a risk up front, there's at least a chance to revisit assumptions when it takes longer than anticipated for the team to come up to speed.
4. Will the project be solving a new problem or using a new technology?
Most software development projects involve an element of discovery; many unknowns are clarified during requirements and design. Projects facing a completely unfamiliar territory will increase the level of uncertainty and the duration of uncertainty as the project team learns about the problem space and the solution space.
This is the one risk my first project didn't face; we knew the application, the problem and the technologies. But if you are facing this risk, build time for exploration into the schedule. And build in frequent checkpoints to test whether the initial assumptions about benefits still hold true based on current knowledge.
5. Is the technical infrastructure in place?
We shared the test environment with the production support team—and production support had priority. Because there was only one environment, every time there was a production problem, the development team had to make way for the production team.
A dedicated environment makes development and testing much easier. If a shared environment is the only option, close management and coordination is a must—and the task will probably fall to the project manager. It may not be possible to cost justify an additional test environment for one project. But consider tracking the effects of lost productivity (downtime, reloads, re-creating data, and re-running tests) for your project. It may just help get a dedicated test environment for the next team.
We also shared the programs with the production team: every time the production team made an emergency fix, the development team had to manually merge the change into the program version we were working on.
Configuration management software automates the process of tracking program versions and merging changes. This reduces the chance of missing the emergency patches that have been made to released code. It also makes it less likely that the wrong version of code will be included in the final build.
6. What is the relationship between the customers, users, and the technology team? Do they have a history of working in partnership or is has the relationship been rocky?
My customer group had a history of mild dissatisfaction and grumbling…which grew into outright animosity.
Study after study reports that customer relationship and involvement is one of the most important factors in project success. Starting out with a less-than-positive customer relationship will make the project more difficult. Acknowledging past problems and reaching agreement on how to work together in the future can help get the relationship back on track; building frequent milestones into the plan, and then meeting them, can begin to rebuild confidence and trust.
If the relationship is ruptured, or the customer is unwilling or unable to participate to the level necessary, project objectives will be at risk.
7. Is the implementation target date based on realistic estimates?
My project was handed a target date the day we started. We tried to estimate, but we were really just doing guesswork based on faulty assumptions. And we didn't have a way to adjust target dates when it became clear that the project was bigger than anticipated.
In the best of all possible worlds, no project manager would be asked to agree to a delivery date without adequate time to scope and estimate the project. In real life, unfortunately, it happens all the time. Sometimes you can negotiate the date, sometimes you can trim the features; but one way or the other, there has to be some reasonable means of negotiating one of the key factors—schedule, scope, or resources. And once targets have been reasonably established, there needs to be a way to account for changes that will impact targets.
Actual software development work isn't the only thing that will drive the effort and schedule for the project. Each "NO" answer to the questions I've asked here will add to the difficulty and duration of the project.
8. Do you have the project management skills you need?
On my first project, I didn't know what I was getting into. I didn't even know enough to
know I didn't know. My manager thought he was helping me by giving me an opportunity—but he didn't know much about project management either, and didn't provide any meaningful support.
This is the time for some brutally honest self-reflection. If you haven't managed projects before, or haven't managed projects as large as the one you're looking at, will you have the support you need to be successful? Is there someone assigned to be your mentor and coach? Is there someone who you can go to make sure you're on the right path? Strategize with? Bounce ideas off?
If you're not ready, you’re not doing anyone a favor—especially not
you—by taking on the project.
As I look at this list, I see that my first project missed the mark on almost all of these questions. I'd like to think my experience was a fluke, and that I'm the only person who was ever in this sorry position. But the experience I've gained consulting with project managers in many organizations since then tells me that it isn't so: managers continue to put inexperienced and untrained people in charge of projects, and organizations continue to undertake projects that they're just not ready for.
That first project of mine finally did finish, albeit late and over budget, further stressed by some problems in production due to defects we didn't find before we went live. But I survived, and so did the project team—although not without some hurt feelings and resentment. The databases we installed and the code we wrote continued to perform adequately until the entire application was replaced in 1997, long after I'd left the company. As for the rest of the team, they've all moved on, found good therapists, and we’re applying what we all learned to new endeavors.
You, too, will survive the occasional project from hell. But to improve your odds, use the questions I've asked to perform a risk analysis when considering a new assignment. If the project doesn't pass this sniff test, consider declining the opportunity to manage a mission that is starting out in trouble. If walking away isn't option, work like hell to keep your project from
going to hell. Take steps to mitigate risks and negotiate for outside support to get the help you need to be successful.
###
Esther Derby (derby@estherderby.com) has developed software and managed projects for over twenty years. She's learned a lot since her first project, and now runs a company that helps other project managers and their managers to be more successful.
|
