Organizations moving to agile methodologies naturally have to embrace self-organized teams, which can leave managers wondering where they fit in. While introducing teams to agile, I often have the opportunity to help these lost managers figure out their new role. One organization I worked with recently had one manager for the developers on the team -- we'll call this the Technical Manager -- and another managing the relationship with the business stakeholders -- the Account Manager. Both managers were new to these roles; the organization had split responsibilities between technical ownership and the business relationship just a few months before. Both managers were having difficulty figuring out where they fit in the grand scheme of things, but for different reasons.
The Account Manager's (AM) biggest question was "What do I tell the business?" He struggled with how to convey information to the team's stakeholders. The AM thought he needed to provide the stakeholders with their accustomed status information -- for example, how long specific features would take to deliver -- even though the delivery team often struggled to provide that type of information. Part of the problem was that the team had difficulty sizing their work and breaking it down into consumable chunks of work. More importantly, though, no one introduced the stakeholders to agile approaches and explained how the new approaches would impact their experience. Over the years, the delivery team had done a very good job of training their stakeholders to expect hour and dollar estimates, so the stakeholders didn't know how to react when they no longer received that type of information.
Most stakeholders in enterprise-driven efforts do not live in a project-focused world. Their knowledge of project work comes from the project teams they work with. They have been taught to expect hours and dollars. When the project team changes that up, stakeholders naturally rely on the delivery team to explain the difference. Otherwise, they expect the same type of information they have always received.
In this situation, many of the problems were of the organization's own making. The AM belonged to an IT area that played a big part to play in establishing stakeholder expectations to begin with. Like all IT departments, they had trained their stakeholders to expect certain things. Likewise, the delivery teams had conditioned their stakeholders to provide very specific details about what they wanted, often details that they weren't knowledgeable enough to provide.
Teams reinforce this behavior (sometimes even in agile) because they tend to want very specific details to start from, instead of starting at a broad perspective and gradually discovering what the stakeholders want to accomplish. This is what an account manager, product owner, or business analyst should really be doing, not working as an intermediary between the team and the people whose needs they are supposed to meet. So the AM's role may change in an agile environment, but it's actually returning to what it should have been in the first place: helping the stakeholders understand what they are really trying to accomplish, and getting stakeholders and teams together to come up with the simplest, most elegant solution to make that happen.
If your organization is making the shift to an agile approach, tell your stakeholders what you are doing and why. Explain how things will look different for them, and that if you do it right, things will actually improve. Agile at its core (and hopefully we get to the point where we don't have to label it as such) is about delivering solutions in a way that makes sense. What stakeholders really need to know, whether they will admit it or not, is not how long various features will take to produce, but when they will be able to do certain things with the solution.
Our AM's other challenge was that one of his employees was acting as product owner and didn't seem to be giving the AM the information he needed to keep the stakeholders informed. In an ideal situation, one of the key stakeholders would act as the product owner, but in many enterprise-driven situations someone belonging to the IT organization (often a titled project manager or business analyst) fills the role. These enterprise product owners do not necessarily make the key "product" related decisions, but they facilitate the process to make those decisions happen.
In this particular case, this role shift caused a bit of difficulty because, effectively, it was supposed to be a function of the AM role, at least as far as I could tell. Part of the problem was that the AM role itself was new to the organization, so adding an agile approach and establishing a separate product owner caused a great deal of confusion.
The Technical Manager (TM) had a different problem. She was confused about what her role should be. She was used to spending most of her time on "resource planning" -- an organizational euphemism for moving people project to project, resulting in overloaded people and a complete lack of continuity. Her direct reports, often callously referred to as "resources," were constantly reassigned, and often overloaded with 6 to 8 projects at once. Her time was spent analyzing the project pipeline to figure out what new "resources" she needed or where she could pull "resources" from one project to staff another.
I don't like the term "resource" because it reinforces the cog-in-the-wheel perception that pervades traditional project thinking. People cannot multi-task, and they are not effective when trying to do so. When you assign people to many different tasks, they will be forced to do a lot of context switching, and will waste more time in the process.
The move to agile shifts the atomic planning unit for a project from the individual to the team. If you truly build cross-functional delivery teams, you don't have to move people to where the work is. Instead, you bring the work to the team. This reduces context switching by people working on the project. Perhaps more important, it frees up managers to work on things that deliver more value, like figuring out how to develop their team members and remove as many productivity obstacles as possible.
In this organization, the TM felt that she didn't have a place with agile, but truth be told, she had a very important role to play. She helped remove obstacles for the team to keep them effective. Plus, under agile approaches she could focus more attention on helping her team members improve.
In effect, managers in this situation are actually able to become leaders. If you still insist on using the resource term, managers can keep the "project resources" in good working condition by supporting them and helping them to improve their skill sets. I'd argue this is what managers should be doing. Unfortunately, people are just now starting to realize that if they trust their employees more, they do not have to do things that their staff is certainly capable of doing, such as planning work and problem solving.
Many managers believe they have to do those things because their staff can't. Ironically, they'll never really know unless they give their staff a chance to try it and fail -- which, by the way, is the best learning experience someone can have. Middle managers often complain of being overworked and in very difficult situation, but it's often a problem of their own making. Generally speaking, managers do not actually produce tangible work product, so they have to demonstrate their value through other means (like ordering their team around).
Adopting agile usually does not cause the dysfunctions that arise during the process. Instead, agile shines light on dysfunctions that have been there for a while. Luckily, agile may also provide ways to address those dysfunctions, often with a simple approach. In this case, I think agile approaches help managers get back to the type of work they should have been doing from the start.
Mike Cohn recently wrote a blog post about The Role of Leaders on a Self-Organizing Team that provides some other perspectives on how leaders may want to interact with their teams, and how team members can influence that interaction. Jeff Weiner also wrote a blog post on The Importance of Scheduling Nothing that provides managers in this situation with a way to use some of their newly discovered "free time" to make themselves more effective and be in a position to better help their teams.
I'm writing this in the Denver Airport as my wife and I are returning from our trip to Big Bend National Park. While we were on this trip, I got a reminder that it was my turn for an article, and it occurred to me as we were on one of our many hikes, that the story of our trip held some great project management lessons. I thought I would share some of those main lessons here.
"Why Big Bend National Park in January?" you may or may not be asking. This was an opportunity to mix a couple of our interests. My wife enjoys running long distance races, from 5K to the (very) occasional marathon, and has set a goal to run a race in every month of the year. I have a goal to visit every National Park in the United States. This past Sunday the Big Bend Ultra race took over Big Bend National Park with a 10K, 25K, and 50K. When my wife saw an article about the race in Runner's World Magazine last April, we immediately saw the opportunity to celebrate her upcoming significant birthday (Tuesday the 21st), give her a chance for her run a race in January (her first trail race) and to visit National Park number 17 out of 58. (Now 59. More on that later.)
Allow me for a minute to extend the trip as project metaphor to extreme lengths and put this particular trip in overall perspective. You could think of the effort needed to satisfy both of those goals as a separate Program. The Run a Race in Every Month program is the smaller of the two, with a clearly defined time frame (one year), and fairly manageable constraint -- at least one race a month, with no limit on where the race is, so we don't have to travel to terribly far to accomplish this goal (although it is a bit difficult to find races in Iowa in January). The Every National Park in the United States program is a bit larger. Officially, there are 59 National Parks including 8 in Alaska, at least 2 of which are above the Arctic Circle, one in American Samoa and one in the Virgin Islands, not to mention all of the parks dotted across the Western United States. We're very quickly working our way through the ones that are within driving distance, so are soon to run into a constraint driven by travel budget and available time for the trips. Due to the size of this effort we look for ways to incorporate multiple parks, or other interests into the trips we take.
So as we began to plan this particular trip, which you could consider a project to satisfy parts of two Programs -- you have to take those opportunities whenever they came up -- we knew we had to structure the plans so that my wife could run the race in a time she could be proud of, and we had to make the most of our visit to Big Bend National Park. In other words we needed to know what success looks like.
For this particular trip, we needed to define success based on making progress on the two programs I mentioned above. These success criteria translate into two key objectives we had on this trip were:
We of course wanted to have an enjoyable time as well, but I didn't want to stretch the analogy beyond ridiculousness (it may be too late for that).
When using objectives to guide a project, it's always extremely helpful to define the objectives clearly so that there is no question whether the objectives were actually met. For that purpose, here's a little more on how we defined each of the objectives. The first part of the race objective is fairly straightforward. My wife wanted to finish the race (usually this means she runs across the finish line before they course is closed.) The satisfactory time aspect of the objective is a little sketchy. In my wife's case "satisfactory time" depends on the race and how she is doing leading up to it. In this case, she was targeting to finish the race in less than 55 minutes. As it turns out, she finished in just under 53 minutes and was two days away from winning the Master's Women's class, so all in all a good race.
The criteria for a successful visit of a national park is not measured by a specific measurement, but is a yes or no based on a couple of rules, which have evolved over the course of the program:
The trickiest part of this is probably remembering to bring along the Passport book, and then remembering to get it stamped. It's now become standard operating procedure for us to stop at the first open Visitor's Center we come to inside the park, get the passport book stamped, and ask the Park Rangers for suggestions on what their favorite parts of the park is what we should "not miss." The requirement of the stamp in the National Park Passport is open for interpretation, since the Every National Park in the United States program officially was declared after I had visited four of the National Parks. I count them in the overall total, but suspect I will make it back to them before the program finishes.
On this particular trip we got the passport stamp taken care of early, and since we had a solid three days in the park, we were able to take in the sites, and go on several good hikes, including a delightful 11.6 mile hike on the day we were due to leave the park that took us up 2,000 feet to a wonderful overlook of the entire park called the South Rim Trail.
When I first made my goal to visit all of the National Parks, I quickly found I had to be very specific about what that really meant. The National Park Service currently manages 392 locations. If I tried to visit each one of those, I would probably not be able to do anything else. Instead, I set the target at visiting the actual National Parks, not to be confused with National Monuments, National Preserves, National Reserves and the like. The National Park Service is even a little vague on the difference, but the easiest way to tell if something fits is the official name of the area. To keep it very clear, I made an explicit list of sites that need to be visited, as well as the ones to which I have already been. Explicitly listing what is included in scope clears up any confusion and provides a source to point back to. This is especially important when talking to stakeholders that may have only a passing understanding of what you are trying to accomplish. In my case, that's my father-in-law, who constantly asks if we've been to a particular park in our quest, and is usually referring to a National Battlefield Park or National Historic Park. Having a specific list provides a nice reference point for those clarifying discussions.
Having the clear statement of scope also is helpful when scope changes. In my case, I have the United States Congress to thank. On January 10, 2013 the president signed legislation that converted Pinnacles National Monument into Pinnacles National Park, the United States' 59th National Park. My dad had asked me a year or so ago what would happen if more national parks were added while this program was underway, and I indicated that I would add them to the list. I probably would not have visited Pinnacles had it stayed a National Monument, but now that it has reached National Park status it's on the list. If you work on projects in regulated industries, no doubt you can relate to my situation.
Probably the biggest project management lesson we learned on this trip was to not feel beholden to rigid plans. When we had originally laid out our travel plans, we had heard that Big Bend National Park was 250 miles from the nearest airport. So we planned to fly into Midland/Odessa, stay there overnight and then drive down to Big Bend the next day. We did the same thing on the way back, driving back to Midland Odessa the day before we were scheduled to fly out. We did this primarily to account for possible flight delays, of which I seem prone to recently. However when our flights went disconcertingly smooth, we found ourselves driving around Midland at 1:00 PM wondering what we were going to do to occupy our time. We quickly decided it would be worth a couple of phone calls to see if we could start our time in Big Bend much sooner. As luck would have it, the lodge in which we were staying in Big Bend had open rooms, and we were able to cancel our reservations in Midland, thus giving us almost an extra day to experience the sights and trails in Big Bend. Had we not made that switch, we probably would not have been able to do as much hiking and see as much of the park as we ended up doing.
We changed our plans coming back as well. Deciding the schedule change fees were worth it to get back home at noon instead of 6 pm or later and start getting adjusted back into the flow of things at home. This put us in a position where we are able to be much more productive doing laundry and getting the house back in shape rather than cooling our heels in an airport all day.
As we continue to strive toward completion of our two Programs, we'll continue to take other trips that capitalize on these lessons learned and others. We set an initial plan to make the airfare and hotel reservations in advance when we need to, but also set up situations where we can make changes as the situation warrants to improve the enjoyment of our trip or increase the actual time focused on satisfying the objectives of that particular trip. Our next "project" is a trip to Las Vegas over Spring Break where we're adding another interest into the mix. We're going to catch a college conference basketball tournament in Las Vegas, my wife has found a race to run, and we are going to visit Death Valley and Joshua Tree National Parks.
I have been working in a project environment for over 15 years, first as an application engineer and program manager for an automotive parts manufacturer, then as a business analyst, project manager, or program manager in a variety of information technology projects. What is the common denominator in all these projects? Documentation. My role on most of those projects could easily appear to be all about producing documentation. On top of that, I love writing, one of the reasons I write this column. So you would think I would be a huge advocate for producing documents on projects.
I am not.
Don't get me wrong, project documentation has benefits, when done correctly. Project documentation also has costs which are often exacerbated by the amount of documentation teams choose to produce, the way in which they produce it, and the way they use it. At its core, project documentation exists to aid communication and to serve as institutional memory. Many project teams run into problems when they start believing that documentation is intended to be the main form of communication, the primary storehouse of knowledge about the project, and a means of tracking progress in the project.
Piling these different expectations on project documentation leads teams to produce more documents than they really need, produce them in inefficient ways, and place way more importance on their completion that is warranted. When teams keep the proper perspective about documentation, they tend to experience many more of the benefits and fewer of the costs involved with project documentation. I would describe the proper perspective as that expressed by Ron Jeffries several years ago on an agile discussion group:
There are two types of documentation:Let's take a closer look at both of these types of documentation and some appropriate ways to handle each one of them.
The documentation that your stakeholders explicitly request is part of the solution that the team is trying to deliver. This kind of documentation includes user guides, support documentation, and operating instructions, among others. A good way for handling this type of document is to treat them as if they were a feature. When a stakeholder requests a particular document those requests get sequenced along with everything else so that stakeholders can decide whether new functionality is more important to them than the documentation. If you find that the documentation is important, determine why they are asking for it and what they hope to accomplish with it. Watching the stakeholders do their work can be a good way to understand why the documentation might be needed.
Armed with that knowledge you can craft the document specifically to meet that purpose. Don't try to use design documentation, which was intended for conveying a design, as a way to convey information to those trying to maintain the system. The design documentation may not accurately reflect the system's final state. Plus, that document was structured to convey design information, not to provide a quick guide to how the system was actually built.
When you know what documents are needed and their purpose, determine the best time to create those documents. In some cases, it makes sense to work on the document as you build the system (help documentation, for example). In other cases it makes sense to create the documentation after the system is built. Either way, write the document specifically for the intended purpose.
It also is usually a good idea to craft these documents at a system level, rather than a project level. Most of the consumers of the documentation do not care which project implemented a certain set of features in a product or system, they care more about the system as a whole. Since they are looking for information in this context, producing documents with this same perspective instantly makes it more useful. If information about a system is split into multiple documents depending on which project implemented the system, users may never know where to look to find the documentation they need. The other benefit of this approach is that you don’t have to create a new document for every project that touches a system; you can just make the relevant updates to existing system documentation.
The other type of document is those things that the team needs to do their job effectively. The vast majority of the documents project teams create fit into this category, but if you really take the wording to heart (those things the team NEEDS to do their job effectively) many of those documents actually go away. When the team relies more on face-to-face discussions on an as needed basis, they find that the documents now primarily aid communication and serve as institutional memory.
These documents no longer act as the sole means of communication, or as the only vehicle by which knowledge is transferred from one person on the team to the other. Looking at what they have to do, the team finds that they have been creating many of their documents because it was what they have always done, or because it was mandated by their process. Once the team identifies which documents they actually find helpful, they can focus on creating those, and using them in helpful ways, and abandon the documents that don't add any value.
So the benefits of documentation come into play when it satisfies a need that a stakeholder has or it helps the team become more effective. Documents add cost when they are not requested by a stakeholder, or if they get in the way of the team effectively meeting their objectives.
When I talk with teams adopting agile, there are two groups that seem to have a bit more consternation adopting the new method -- project managers and business analysts. Perhaps I notice it because those are the two roles I usually fill. More likely it's because those roles are specialized for phase-based project approaches, and their applicability in agile projects is not as obvious.
To understand where project managers fit in an agile project, it helps to know what roles exist in agile. The different agile approaches have different titles for various roles (because the agile community apparently likes to make up new words for stuff). I chose to use the labels created by Scrum because they tend to be the most commonly known in the project management community.
The Scrum Master acts as a facilitator and guide, helping the team with the agile techniques they choose to adopt and with good software development practices in general. They facilitate key team discussions, and help the team figure out how to apply techniques and continuously improve their approaches. The Scrum Master also clears obstacles that prevent the team from being as effective as possible.
The founders of Scrum picked the unfortunate title of Scrum Master for this role to indicate the difference from traditional roles on project teams, and to indicate that the person filling this role needs to be well versed in the principles and practices of agile techniques. I prefer the term Coach, but it has developed its own separate definition with the rise of the agile coach -- meaning an advisor that specifically helps the team with agile practices, but may not be considered a part of the team.
A Product Owner is someone with a need that the team is trying to satisfy. In an agile project, the Product Owner makes decisions about what features the product should have and the priority of those features. This role represents the perspective of the business, so you want to have close communication between the person or people who have a need and the team trying to satisfy that need. In some cases the people with the need are not readily accessible, either because of their position in the organization, or because the product is intended for sale to the broader market. In either of these cases, you need someone who has a good sense for what the needs are and can make decisions in their stead. You can think of this person as a client proxy, and they may have to become very good at balancing the needs of several users, customers, and stakeholders. The idea behind this role is to provide a readily available source for information about the product and priority decisions about features.
The Team is the group of people who deliver a product that satisfies the needs of the client. It includes all the people with the skill sets necessary to deliver the product, usually people with analysis, user experience, design, development, and testing skills as well as others. The lack of distinct role definition among team members is intentional. It reinforces the idea of a cross-functional team that focuses on having all the necessary skills as opposed to a collection of roles. The team determines how much they work on in an iteration, who is going to work on what, and how they approach the work. The assumption is that the people doing the work are the ones who know best how to do the work.
A Stakeholder is anyone who impacts or is impacted by the project. In effect, this label could apply to all the roles, but for our purposes here, stakeholders are identified as everyone who doesn't fall into one of the other three roles but still has some interest in the project. Of particular interest in this group are the actual users of the result of the project (I'll refer to that as the product for simplicity's sake), the people who buy the product, if the team does not have direct contact with them (think "customer"), and people in the organization who play a cursory role in developing the product and supporting it once in production.
So where do project managers fit? It depends on the nature of the individual and the nature of the project.
If you find that your project management style is to work closely with a team or could be described as "servant leadership" -- teaching more than telling, facilitating more than directing -- you may find that you can slide into a coach role very easily. You may need to increase your understanding of agile values, principles, and techniques first, but having the coach mindset will help.
If you find that you spend most of your time as a project manager focusing on what the project is trying to accomplish, worrying about product scope, and figuring out the business implications, you may be able to act as a product owner, especially in those situations where the actual sponsor or clients are not easily accessible. You actually would be more of a client proxy, which has become more common as the adoption of agile has spread. Brush up on your analysis skills before tackling this role, because these are critical to success as a product owner. If you're one of the former business analysts who only switched to project management because it seemed like the next best step on the career ladder, you may find yourself sliding into this role.
Perhaps you have a background in development or testing, and got into project management because it looked like a good career move at the time. Now that you are there, you may realize it's not quite right for you. Agile provides a great opportunity to move back into development and testing and while applying the project management skills you learned. You can become a member of the team doing development work, but also helping the other team members with estimating, and figuring out how to get some of the work done. In this case you may need to brush up a bit on your technical skills.
Finally, if you were born to be a project manager and like to coordinate the activities of others, there is still a need for this role, especially on more complex projects. You may have to revise your leadership style, especially if you tend to act with a command and control mind set. You will find that trying to dictate modes of operating to a set of self-organizing teams will cause a great deal of tension in the project team and will greatly reduce the overall effectiveness of the team.
So how do you know which projects require that type of coordination?
The Context Leadership Model is a handy model for determining how the nature of the project drives the need for project management. This model was created by Todd Little at Landmark Graphics. He took a look at his project portfolio and examined the projects on the basis of two primary sources of risk -- uncertainty and complexity. Understanding how uncertain and complex a project is helps you to determine an appropriate approach, and as a result the appropriate style of leadership needed for the project. The four project types are:
Sheepdogs (low uncertainty/low complexity): These projects have clearly defined scope and are ones the organization does quite frequently. These projects require a minimum core set of practices and little to no process ceremony. Basically you want to leave the team alone to deliver.
Colts (high uncertainty/low complexity): These are projects that introduce a new product, service, or process or are adopting new technology. These projects require a small team working close together in frequent iterations to get continual and rapid feedback. They also require a leader who has a good understanding of the source of the uncertainty (whether it is business, technology, or both).
Cows (low uncertainty/high complexity): These projects usually involve mature systems that are core to the organization's operations and therefore have several interfaces with other systems. These projects usually have large project teams (or preferably several small teams) which increases the need for coordination and published interfaces.
Bulls (high uncertainty/high complexity): These projects usually involve new products, processes or services that require the core systems of the organization. An appropriate approach to dealing with these types of projects is to split the effort up into a focus on the uncertainty and a focus on the complexity. As a result these projects require coordination, strong communication, and an understanding of the sources of uncertainty.
Projects with high complexity (those classified as Cows or Bulls) generally require someone with traditional project management skill sets to coordinate the several moving parts that these projects usually contain. Those moving parts may be the multiple cross-functional teams created to scale the project, or the multiple other teams impacted by the project. When you fill this role remember that you are coordinating the work of a set of self-organizing teams, so you should plan on spending more time facilitating discussions and gauging whether you should stand back or step up in your interactions with the teams.
So when you get an opportunity to work on an agile project, think about the type of work you like to do and how you like to approach project management work. You may find that you can fill one of the roles usually associated with agile projects, you may find that the project is complex enough that it needs coordination, or you may find that you are not a good fit for that project. Going through that thought process before you start on the project will save a lot of frustration and wasted time in the long run.
I recently finished reading How Wars End: Why We Always Fight the Last Battle by Gideon Rose. The main message of the book is that the United States of America has a habit of doing a lot of good planning for war, often based on lessons learned from past struggles, but doesn't do a good job of thinking about the ensuing peace. This was a book about political and military history, but in my never-ending quest to apply lessons from history, I think there are some things we can learn for our project teams. A good analogy can be drawn between "planning for the peace" during war and planning for what happens after a project finishes.
What does it mean to "plan for the peace" in a project context? In the Guide to the Project Management Body of Knowledge, the "Close Project or Phase" process in the Project Integration Management Knowledge Area includes an output specifically called "Final product, service, or result transition," described as follows:
This output refers to the transition of the final product, service, or result that the project was authorized to produce (or in the case of phase closure, the intermediate product, service, or result of that phase).
And that's all it has to say about worrying about what happens after the project is over. Is that a huge oversight in the world of project management? Perhaps. More likely it's a reflection that planning for after the project is not just a project management issue. It's an overall project concern. In other words, part of the outcome of the project is figuring out how to make that outcome happen.
The Business Analysis Body of Knowledge recognizes this need to "plan for the peace" by introducing the concept of Transition Requirements. In the words of A Guide to the Business Analysis Body of Knowledge:
. . . [transition requirements] describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state.
To extend the military analogy (perhaps stretching it to a breaking point) planning for the peace needs to occur as part of implementing the war.
Planning for the peace consists of getting to a peaceful state, and determining what to do once we get there. The BABOK® Guide idea of transition requirements helps us get to the peace. This line of thinking takes into account things which may seem technical in nature, such as initial data loads or data conversions that need to occur as a result of a new system or a system update. For example, one project I worked on added a new source to an existing data warehouse incrementally. Each time we added a new increment, we had to perform a historic load of data from the source system. In order to do this as efficiently as possible, we planned for this process and established specific procedures that we followed every time we did it.
Other transition considerations include how the outcome of the project will be deployed to users, which can influence the order of project implementation. Agile approaches help address this transition need by only developing the necessary features for the customer base targeted for first delivery. In effect, give the initial customers something, get their feedback, and then decide where to go from there.
There are several questions to ask when thinking about closing a project. It's probably a good idea to ask and answer these questions sooner, rather than waiting until the week before the end of the project.
Will your stakeholders (customers or users) need training to use the solution? This is especially important when you are developing a new application or making changes to an existing one. Consider what that training needs to look like. Is it fairly extensive hands-on training that will take a day or two, or will a one-hour overview of the changes be sufficient?
Will your users' work need to change as a result of your project? In many cases, changes in process drive scope in a project, but sometimes outcomes introduced by projects require corresponding changes in a business processes or in a stakeholder's day-to-day work. During the project, are you including the people that would be able to tell you whether their work is changing? If their work is changing, what should you do (if anything) to help them make those changes?
How will you support (or do you need to support) the outcome of the project? There are a couple different things to consider here. One is the "maintenance period," where the project team is available to react quickly to issues that the stakeholders run into right after the final deliverable is released. The other is the question of longer term support. If you know the outcome of your project will be supported by someone who is not on your team (e.g. an operations group) include someone from that group on your project team during the course of the project so that they can start getting familiar with the outcome. At the same time, figure out what information that support group would like persisted and in what format, so you capture the necessary information. If possible, have the person from the support group create whatever documentation is needed. After all, they will be the one most familiar with what information is needed. (They will, of course, need some help with knowing what to write.)
How will you measure whether the project was successful? Here, we are not measuring success in terms of scope, time, or cost, but rather what business objectives the project will meet. The tricky thing with this one is that you can't always tell whether a project was successful immediately after it ends. Often the outcome has to be introduced into the wild and used for a while before you can tell whether the objectives are met. Identifying the objectives you will look at, how you are going to come up with those measurements, and who is responsible for doing the measurement are all things you want to figure out during the project, because additional work may be required to make those things happen.
If you are replacing an existing system, when do you shut that existing system off? Many software projects that start off as a system replacement never seem to get to the point where the old system can be shut off. For one reason or another, every area using the old system doesn't move off of it in a timely manner. This is perhaps one of the biggest dangers in approaching system replacement projects, so it's part of planning for the peace that actually needs to happen when you are planning the war. Is the main goal of your project really to replace an existing system? At the heart of the matter, does that even make sense? Resist the urge to start a systems replacement project for the sole purpose of replacing an existing technology without allowing any changes to how business is run. Instead, look at what capabilities you need to continue to have and the best way to deliver those capabilities. Looking at the project from that perspective, you are less likely to implement a new system that includes all the broken processes from the existing system, and more likely to provide only the capabilities that are really needed.
Sometimes you are unable to completely replace an existing system because you ignored or underestimated the political aspect and can't drive the necessary adoption. This is a clear analogy to what happened with most US wars in the 20th and 21st centuries. Militarily we had a pretty good handle on what we wanted to do, but politically we dropped the ball. The same thing happens with many projects. Technically your project team is able to work through most of the issues that prohibit implementing a new system, but politically the ground work isn't done to get the new system adopted throughout the organization. This can often happen when the focus of the project is on replacing a system rather than providing capabilities. Project work is demanding, so it's easy to see where project teams can lose sight of what happens after close-out. As they near the end, many teams just want to be done and move on to the next thing, so they may not consider all the niggling post-project considerations. This inevitably leads to issues that the team has to go back and fix later. Planning for how you are going to get to the peace, and what things look like when you get there, will make the end of the project that much more satisfying and will allow you to truthfully declare "Mission Accomplished."
One success factor for project teams is that all the team members are focused solely on that one project. Agile approaches offer a person the ability to focus, but removing external distractions is not all that is needed to get focus to occur. Team members also need to have some self-discipline to keep that focus. I've always assumed that knowledge workers would prefer to be able to focus on one thing at a time, but I have found several cases in the last few weeks where knowledge workers suffered from the "Ooo Shiny Syndrome" and got distracted from their main responsibilities.
A team I worked with recently had a problem staying on focused on one task. They work in an agile environment, and given the lack of prescriptive processes, commitment and self-discipline are key characteristics for success. The team would commit to work on a particular backlog item, and several of the members would invariably find something else they thought was more interesting and work on that instead, ignoring the tasks they had committed to and slowing progress. It's a perfect example of the Ooo Shiny Syndrome.
Ooo Shiny Syndrome is difficult to overcome. I know, because I occasionally face the same affliction during my own work. But the damage I inflict when I distract myself generally only hurts me. In a team environment, this syndrome can be particularly harmful. If team members continually ignore the work they committed to in favor of something else which seems much more entertaining, they stall work on the important things that led to a team commitment in the first place. This slows the overall progress of the project.
So how do you counter Ooo Shiny Syndrome? There are no easy answers, especially if you are working on an agile team that does not want to go back to micromanagement. The approaches I find most helpful all center around helping team members strengthen their self-discipline.
There's a difference between coaching someone to strengthen their self-discipline and micromanaging team members. In this case, some of the team members tried to hold their teammates accountable. But it was a fairly new team, and the relationships were not terribly strong yet. As a result, the team members who were being held accountable felt like they were being attacked.
The team members had every right to expect everyone to pull their weight, but sometimes it comes down to how that message is conveyed. One way is to avoid being too accusatory when trying to keep everyone on task. "Well what have you been doing all day?" may not be the best way to open that conversation. A less confrontational approach is, "I notice this task has been in progress for three days. Is there something that is blocking its completion that the team can help with? Or is this item so large that we need to break down into smaller chunks that we can complete sooner?" Focusing on the task itself, not the people who are supposed to be performing them, can help you avoid some defense mechanisms that people may put up. Either way, regular reminders of commitments made can also help people stay on task.
Sometimes, people don't stay focused because they want to dig into something while they are still thinking about it. Help these team members capture passing thoughts for later. You just identified a new risk, a new question you want to analyze, or some new piece of technical debt? Note it on an index card or sticky note and put it in the backlog. You haven't forgotten it, and now you have noted it for further discussion so that the team can determine when it is appropriate to investigate further.
Successful definitions of done, or asking when you'll know when you are successful, are good at many levels. Knowing what success looks like at the product, release, and sprint level is great, and it can be just as helpful to have clear understanding of what success looks like for a particular analysis effort, or even a particular meeting. Use those definitions to give people some indication of when they are done.
In some cases, you may find that you need to break the jobs down into much smaller tasks. Some people have trouble focusing on one thing for too long, so if you break a story down into sufficiently small tasks, it's easier to take one thing and complete it, and then move on to the next one. (Notice how some personal productivity techniques can be helpful here?)
If none of these techniques seems to do the trick, you may have to let the project team fail. The way Agile methodologies are set up, failures result in fairly quick learning, and the overall damage to the project and team is fairly well contained. If your team continues to get distracted and work on things that aren't associated with their actual commitment, they will eventually fail to meet that commitment. When that happens, you can have a discussion around why the commitment was not met. You may have to work through some excuses that didn't really have anything to do with the real cause, but eventually you'll arrive at the fact that people were working on things not directly associated with the sprint.
Ooo Shiny Syndrome can be a pervasive ailment, but it doesn't have to spell ruin for your team. Try countering it with these techniques, or try avoiding it by raising your team's awareness of the importance of making and sticking to commitments and the self-discipline required to do that. Also remind them that no one would really like the alternative -- micromanagement.
There are two sayings that are commonly used when discussing measurement and management: "You can't manage what you don't measure," and "You get what you measure." It seems that several organizations pay a lot more attention to the first piece of advice without heeding the warnings that come along with the second, especially in the realm of leading project practitioners.
I work a great deal in the business analysis space and have seen this happen quite frequently there, but based on anecdotal information it occurs just as frequently for quality assurance/testers and developers. Basically the leaders of these knowledge workers want to find some way to gauge how well people are performing their jobs. These measurements are then used to determine development opportunities (hopefully) and for the purpose of performance evaluations (more likely). This seems most common in organizations that like to refer to people as "resources" and group them together in teams of similarly skilled people. In other words, all the business analysts are in one group, all of the testers are in another group, and all of the developers are in a third group.
On the surface, this approach makes sense. Everyone with the same skill set is grouped together for purposes of career development and training. The more experienced BA's, for example, can share their experiences with the less experienced BA's, and they can all share good practices. Since their department heads usually used to do the same job, these groups are supported by leaders who understand the ins and outs of their particular skill set. The thinking then goes that grouping people by skill set allows for easier measurement and evaluation, since they can all be measured by the same criteria. That's the idea at least.
But measuring knowledge work can be tricky. Do you measure productivity? (How many use cases can you complete in a week? How many lines of code can you write? How many bugs can you find?) Do you measure based on quality? (How many "errors" did you not put into those use cases, lines of code, or test scripts?) Do you measure based on performance to goals? (I said I was going to write four use cases this week, and by golly, I did.)
All of these approaches certainly provide useful information, but settling on one approach—or even combining metrics from different approaches—applies focus in the wrong place. If a business analyst is measured based on how many use cases they produce, use cases become the end product for that business analyst. If developers are measured based on how many lines of code they produce, the code will become very bloated, and probably not particularly efficient. Testers measured based on how many bugs they find will suddenly detect an infestation that may or may not actually exist.
One organization I recently heard about introduced a new measurement regimen designed to make their business analysts more effective. Their business analysts set weekly goals, and then compare their actual accomplishments with those weekly plans. So far, not too bad; this approach recognizes the need to frequently revisit and revise plans based on the latest information, and encourages the business analysts to do a little forward planning once a week in order to get organized.
A trickier aspect of this measurement program is that the goals that are set are based on how much time is spent doing particular activities, and the work is evaluated as value added or non value added. The value add of a particular task is determined based on whether it is actual business analysis work. So, writing a use case? Value added. Talking to a stakeholder about content for a use case? Value added. Helping another business analyst on another project work through a particularly gnarly analysis problem? Non value added. Helping a tester on their project team write test scripts? Non value added. Attending the team's daily standup? Non value added.
What this and many similar measurement programs seem to miss is that knowledge work is a team sport with the ultimate goal of delighting the organization's customers, not producing requirements, writing lots of code, or finding a lot of bugs. Individual measurement programs encourage sub optimization. Depending on how they are designed, these systems may even actively discourage teamwork. People working under these types of systems will quickly see that in order to get ahead, they can't afford to help anyone else. They have to keep hitting their own individual numbers, because it is not to their personal advantage to collaborate with the other members of the team.
Leading projects in this sort of environment is difficult enough, because as a project lead you typically have to lead through influence. That means bringing people together who report to three or more different leaders, each with different understanding of priority, and with their attention split across multiple projects. Throw a reward structure on top of that which by its very design encourages suboptimal behavior, and now you can't meet your own personal goals, which are usually focused around the legs of the iron triangle. You start making suboptimal decisions yourself trying to work a plan that conflicts with the individual goals of each of the team members. The result is a mind numbing set of discussions where the phrases "that's not my job" or "that's not your job" are heard far more frequently than "how can I help?"
I'm not suggesting you don't measure at all. That would be counterproductive in many other ways. I am suggesting that you change the focus of the measurement from output to outcome. If your organization pulls people together to work as a team, create measurements based on the outcomes of the team's efforts. Did they drive progress toward the business objectives they were seeking to impact? Did they work in an efficient and effective manner? Did they reduce waste in the overall process?
Some people will initially feel uncomfortable with this measurement approach. They may be concerned that they no longer control their fate, that they will be too reliant on team members, and that they will have to carry others' weight. Perhaps, but that will certainly provide some incentive for those team members to help out the ones who may need a little help for the good of the entire team, and for the organization. Placing the focus on the outcome of the entire team will also encourage people to step outside their comfort zone and pitch in on tasks that may not be their direct responsibility, but that they have sufficient skills to perform on a short-term basis. They will become more well rounded and both the people and the organization benefits as a result.
Plus, if you decide to measure based on team outcomes, you might just get them.