VALUE FOCUSED LEADERSHIP

Move Boulders, Don't Throw Pebbles

by Kent McDonald


Project Leaders willingly accept responsibility for protecting the team from outside distractions such as scope changes or demands from other parts of the organization. However, these same leaders often fail to realize that they can be a distraction to the team as well. These distractions can come in many forms, including "suggesting" changes to project artifacts, asking team members to change their focus to work on an urgent, but not necessarily important item, and setting arbitrary deadlines that force the team to sacrifice quality in order to meet a deadline that is not necessary from a value delivery perspective.

Some recent experiences have compelled me to consider this interesting paradox, and provide some thoughts on how project leads can move boulders for their team without inadvertently tossing pebbles back at them.

Could you change those squares to circles?

Truly effective project teams should be adept at harnessing change when it adds to the team's ability to deliver business value to the project's stakeholders. However there is still such a thing as bad change, especially when it distracts from rather than strengthens a team's ability to deliver value. One prevalent example occurs when a project leader, with the best intentions, reviews the project's artifacts to provide "suggestions" (which tend to be more directions) and ask questions. Most of the time these questions help the team to identify gaps in their thinking and end up making the product stronger. When the suggested changes are stylistic in nature, and accompanied by requests to make the changes sooner rather than later, the change becomes a distraction that prevents the team from focusing on their real goal.

Why aren't formatting changes to improve readability a value-add? Unless the product of your project is actually a written document, the true purpose of most artifacts is to help the team accomplish the project goals. They have no real value in and of themselves. Alistair Cockburn, in his discussion of the Cooperative game manifesto for software development describes this idea in the context of software development projects. Since these artifacts are intermediate in nature-meant for use in conjunction with other, richer forms of communication such as face-to-face discussion-the artifacts themselves do not need to be perfect. The project team should stop as soon as the artifact is barely sufficient (another term coined by Alistair Cockburn) for its true purpose.

Does that mean that the project lead should not be reviewing artifacts, asking questions, and providing suggestions? Absolutely not, especially if the project lead has significant domain experience. Project leads often have an overall understanding that most of the team members are not going to have by the nature of their day-to-day activities on the project, no matter how well the team communicates. There is great value-add in the project lead asking questions and providing input to the team based on that overall viewpoint. Some perspective just needs to be applied to make sure that the input is focused on the end product and not on prettying up intermediate artifacts. If those artifacts are truly important for historical purposes, and will be continuously referenced long after the project is complete, time can be taken to preserve them when they are no longer part of the critical path.

A rather large project I was on recently had a great deal of visibility in the organization. The project lead was very focused on establishing artifacts that could be used repeatedly for the multiple project phases, and so was reviewing every version. The project was already behind schedule, and the business analysts were trying to determine (without much feedback) the level and type of information the developers needed to successfully complete their work. At one point while the business analysts were focused on getting content identified to make progress, the project lead reviewed the requirements documents and requested a formatting change to all of the diagrams already created-to be done by the end of the next day. Undoubtedly the change would have improved the readability of the artifacts for some audiences, but not the audiences that were the immediate consumers of the documents in the critical path.

This example showcases the common occurrence of project teams convincing themselves that the artifacts being produced are the main product of the project, something that happens when the production of actual working software seems so far out that there is a drive to produce something in the interim. In this case, the business analysts discussed the priorities with the project lead, delayed updating the documents for a couple of days until they were able to complete more of the critical content, and then went back and revised the format. The project lead got the formatting change, the analysts got their information, and the developers were able to get to work.

I know you are working on that, but I need these TPS reports.

There's a reason that the founders of the Scrum methodology are so adamant that teams are protected from changes during the sprint and are allowed to focus only on the tasks at hand. Context switching can be disastrous to productivity. The team spends as much time ramping up to work on a new topic as they do actually working on the topic. The concept of the sprint backlog is that once the work for a sprint is determined, nothing can change it, aside from replanning the sprint, which is intended to make changes to the scope of the sprint undesirable.

Wait a second, you say, isn't one of the principles of agile to allow change? Sure. But where scope changes occur is on the project backlog, which is the overall list of things to do on a project. The business is allowed to add, remove, or reprioritize items on that list whenever they please. The items at the top of the list when the next sprint planning occurs would be selected for inclusion in the next sprint, based on agreement with the business and IT workload.

Project leads are good at keeping those outside the project team from changing the scope, but they often inadvertently insert scope changes themselves by asking the team to do urgent tasks on a moment's notice. They ask the team to help out on these items in the guise of letting the team participate in creating the plan or deciding what work is to be done. The trouble is, this is often done after the team has already started doing the work. Seems like funny timing, doesn't it? If the team will be involved in deciding what work needs to be done, involve them from the beginning; or at least decide what needs to be done for the next one to two weeks and then leave them alone to go do that. At the end of that period, get the team together again and reflect on what was done and what still needs to be done, and adjust.

An overall project plan had been put together for the project I mentioned earlier, and the business analysts had been sent down a path to start gathering requirements using a particular format. But every time they tried to get moving down a path, they were interrupted a couple days into their work with a request from the project lead to produce some analysis to help with detailed planning or to produce some document to help describe what the project was going to do to some audience-even though the work that actually needed to happen to develop the information for that document had not been done yet. The project team found themselves jumping from one hot task to another unable to focus on the tasks required to truly establish the vision and requirements foundation.

The lesson here: teams will need to try a few things to figure out the best approach, but they need some time (it doesn't have to be much) to actually try things out. Also, while it's an admirable idea to dive in and start gathering requirements while the project lead goes off and plans, the truth is the team really needs a shared vision to 1) know what they should or should not be working on and 2) have enough information to truly put together a plan.

In the case of this project, the team ended up changing their structure from a large group of business analysts, a group of developers, and a group of testers to three smaller cross-functional teams. Each of these teams then took a few minutes to fully understand what aspect of the project they needed to accomplish and to revise the approach they were going to take to accomplish it, as a team. The teams were then allowed the liberty to start chasing those plans, free from most distractions, and as a result began to make real progress.

I need this by tomorrow, because I said you could do it by then.

Back to the original formatting change example; that request was full of pebbles. Not only did it imply that the document was the focus of the project (based on the drive toward perfection over sufficiency), but the deadline imposed seemed arbitrary, short, and not based on value-focused milestones. According to the project lead it was necessary to prepare the documents to share with the sponsors. However, at this time the documents were still incomplete drafts based on the amount of work the business analysts had completed. With the general state that the documents were in, and as the lack of clarity surrounding the project vision later revealed, the time required to make formatting changes to existing documents would have been better spent understanding the business problem and possible solutions.

Arbitrary deadlines of this sort often exaggerate the importance of intermediate artifacts. They also drive the team to perform haphazard work in order to meet the deadline so they can go back to focusing on the truly important matters. If you want the project team to have some ability to self manage, it is important for them to understand what is really driving the key dates of the project. In other words, what key business events need to occur by certain dates to produce the most value? Armed with this information, the team is then in a much better position to decide when things should be done-and to a great extent, what things should actually be done.

Arbitrary deadlines happen at the task level as described above, and also at the project level when it comes to determining when the product of the project needs to be delivered. Often times, even the end goal of a project is not based on any specific business need to have something happen by a particular date. Rather, it is a line in the sand established in some planning document that states that this thing will be available by third quarter 2007. When these deadlines are established without a true understanding as to why, several things can happen. Someone's estimate as to when it would "be nice" to have something done becomes gospel based on how high up in the organization that decision was made, and then great efforts are made to reach that target date, even though it produces something of no real value. A separate, but perhaps equally damaging, result is that the team realizes that the date is arbitrary and the delivery is allowed to slip, and then slip again, and then slip again; usually ending up in a project that is never delivered, or delivered past the point at which it will provide any value.

With documentation the value is not in the artifact but in the knowledge and understanding put together to complete it. Likewise, the value in deadlines and milestones often is not in the milestone itself, but rather in the reasons why that milestone exists. Those reasons provide the project team with the information necessary to make appropriate decisions as to whether particular features should be cut to meet a date or whether there is some flexibility in the date to make sure that critical features are provided.

So what is a project lead to do?

The key is to accept the fact that project leads can be distractions to their project teams. Once you realize that, and know to keep an eye out for it, you can then move to structuring your interaction with the team to enable reasonable times of focus surrounded by opportunities to reflect and adapt. Here are some practices that I have found to be good ways to move those boulders while kicking up a minimal number of pebbles.

  • Understand why the key dates in your project exist. They should primarily be focused on optimal delivery of business value. Make sure that you communicate those reasons with the project team and that they understand those reasons so that they can utilize that information in day-to-day decision-making.
  • Avoid establishing too many arbitrary intermediate milestones. This includes finding ways to remove hard dependencies as much as possible. Plan the project based on features rather than tasks.
  • Don't lose sight of what the final product is, and drive all efforts to that. Don't strive for perfection in intermediate artifacts when sufficiency is good enough. Having open lines of communication among all the team members will help reduce the perceived need for perfect documentation.
  • Plan in detail in short increments and plan only when you need to, not before. Take advantage of having the most current information available when you plan for your next efforts. Outdated plans with deadlines and deliverables that don't make sense anymore can be just as distracting as constant interruptions.
  • Once you have established your scope for a particular time frame, stick to it. If you find your scope changes frequently and that you need to react to that, shorten the time frame between planning periods.

Project leaders rarely set out to distract project teams from their main focus. Many of the behaviors I described in this article are built in reactions to typical project pressures and years of traditional project management training. We can combat these reactions with awareness that our actions could end up hurting rather than helping the project, and with an unwavering focus on delivering optimum value. Both will serve a project leader well in helping to keep the project team focused.






©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy