Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Why do some projects churn, but not make much progress, while others seem to fly by? All projects have a rhythm—and that tempo changes over time. I’ve worked with a variety of teams and have learned something about why some projects seem to flow, languish, churn or end in a reasonable amount of time.

If you’ve worked on traditionally planned projects using a waterfall, iterative or chunking lifecycle, you’ve seen that the project rhythm varies during each phase. In the earlier stages, the project may seem to undergo lots of churn, and you wonder if you can ever define the requirements or if the design will ever stop changing. For projects that “mysteriously” gel, the rhythm becomes clearer and more focused during implementation because the decisions have been made and you’re implementing them. Assuming you have adequate staff, the project marches along to its conclusion. For projects that don’t gel, you may stay in churn throughout the lifecycle, never finding a comfortable rhythm.

If you’ve worked on agile projects using Scrum, Extreme Programming or Feature-Driven Development as a lifecycle, you’ve noticed abundant churn during iteration planning and more of a drumbeat rhythm to the work done in an iteration. But those agile projects that don’t gel suffer from many of the same problems found in traditionally planned projects. Both agile and traditional projects that gel have rhythms based on maintaining focus, removing obstacles and adequate staffing.

Narrowing the Focus

Let’s take a case in point: MassiveProduct has had several releases. In previous releases, some segments of the overall project faltered while others progressed in limited ways; in the current release, one of these, DataTransfer, is flying.

The DataTransfer team decided to use an iterative lifecycle—but instead of preplanning their entire iteration, they specified just one month’s worth of work, à la Scrum. They chose to accept requirements changes monthly (a spiral-within-a-spiral lifecycle).

The DataTransfer team didn’t allow their project staff to move on to other projects or split their time among several projects; instead, they remained focused on DataTransfer’s one-month deliverables. They integrated their testers into the project team and refused to let them move off the project. The project manager removed obstacles as quickly as they arose. At the end of each month, the DataTransfer team delivered their (already tested) product pieces and moved on to the next piece.

The DataTransfer project had two paces. During each iteration’s planning stage, the team felt as they were in churn and that the planning took forever. But once they started an iteration, they felt as if the project moved quickly, and were confident that they could keep up that pace indefinitely. They realized that determining and maintaining their focus was essential to a solid project rhythm.

Removing Roadblocks

MassiveProduct’s overall project manager realized that the DataTransfer team had evened out their rhythm, and asked the other project managers to attempt to reduce churn in their requirements gathering and design phases to increase focus during the implementation phase.

The WebUI project manager took this request as a signal that he could define how to take requirements and test WebUI’s design with his customers—a huge relief, considering the WebUI project’s history.

In MassiveProduct’s previous release, the WebUI team was at the mercy of the people who defined the user interface requirements—everyone on the project and every manager in the company could change them. Consequently, the team had no idea what they’d face when they came to work. The team wanted to use paper prototypes to define the requirements, but product managers were resistant; they wanted to show potential customers an electronic version. As a result, the team slogged through the work and felt as if they never finished anything, completing their work only when the overall program met a “UI freeze” date. The WebUI team worked in fits and starts—just when they saw the light at the end of the tunnel, another user inserted yet another requirement.

WebUI had one pace for their project: protractedly pokey. They never developed a head of steam and forged on through the work; instead, they had to deal with obstacles popping up throughout the lifecycle.

For the new release, the WebUI team project manager decided that something would be different, but he wasn’t sure what. For the first month, it was still OK for the users to be unclear about their requirements, but now, with the overall project manager’s request, WebUI’s project manager decided to actively remove the obstacles to success by defining what the WebUI project would do and when, and how they would take changes in requirements.

The team published a schedule of major milestones, explaining that they would deliver and test paper prototypes, holding off on electronic prototypes or deliverables until the last iteration. They explained when they would take changes to various parts of the UI, and how they’d take changes in chunks—not whenever the changes came in. They iterated on the UI, allowing for plenty of review sessions instead of attempting to complete everything for one final deliverable. It wasn’t easy, but the results showed the value of removing the ongoing obstacles. WebUI still had churn in its initial iterations, but the team settled into a reasonable tempo of creating prototypes, reviewing them and allowing for overall review before committing anything to electronic form.

Adding Staff

With each release of MassiveProduct, FinalWork was on the critical path. The FinalWork team was composed of people who left previous segments of the project to coalesce for the endgame. The team was always starved for people, but fortunately, they knew precisely what they had to complete. It wasn’t technically challenging or sexy, but they knew the requirements and had no external obstacles to negotiate. Instead, they had an internal obstacle: the lack of dedicated staff.

Because FinalWork had no planned staff, no one could start the project’s tasks on time, and certainly couldn’t complete them on time. Starving FinalWork of staff had delayed the entire project.

MassiveProduct’s overall project manager was determined that something would be different this time. For the last release, the project manager had assigned FinalWork as a secondary priority to one of the other project managers, and it was starved of project management attention. FinalWork didn’t require a lot of attention, but did need enough to make sure that its team members weren’t being pulled away to work on something else. For this release, FinalWork had a dedicated project manager, Jenny, assigned a couple of months before the project began. Jenny organized the tasks, making sure that when the staff was assigned, they’d have an appropriate project environment—requirements, dedicated team members and tentative milestones. Jenny collaborated with the team members to confirm the milestones and then stepped out of the way, happy to see the team forge on, making tremendous progress. When the inevitable requests came for them to spend “just a little time” on another project, Jenny helped facilitate alternative solutions, making sure the team could stay focused.

In the Groove

No two projects have the same rhythm—and each project has a variety of rhythms throughout its lifecycle. MassiveProduct’s overall rhythm comprised the segments previously described, each of which moved to its own beat. To make sure that your project develops an appropriate rhythm in its early stages, every team member must know what he has to do and remain focused on his tasks until they’re done. If you’re the project manager, remove obstacles as they arise. If you’re one of the technical staff, present obstacles to the project manager as they arise, and work together to overcome them. Make sure the project team remains focused on one project, and don’t try to time-share people.

If you want to increase your project’s pace, figure out what’s causing the slowdown and try to determine a way to remove that obstacle. If the team is fixated on intermediate goals, refocus it on a wider view to encompass the final goal. If the requirements keep changing, find a way to gather requirements in chunks and deliver them in segments to the other project segments and the users. If your project is starved for people, explain to the overall project manager that you can’t finish (or even start!) the project without adequate staffing—and stick to your guns.

No project is glitch-free, but by tuning yourself to your particular project’s rhythm, you can overcome the rockier early stages and come into the home stretch at a healthy gallop.

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.