From a traditional project management perspective, a big part of the job of the project manager is to ensure the scope of the work is well understood, the work is carried out according to the plan, and that it meets the needs of the client (or management). But what happens when your clients’ needs are continuously changing or cannot be understood?
What happens when you are doing an exploratory project – such as trying to develop a new drug for lung cancer? Or suppose you are just exploring whether a particular plant has any peculiar properties that might make it a good candidate for a medical supplement? What happens if you are managing a government project that is trying to develop a plan for improving project management at the Government level, as required by legislation enacted at the end of 2016?
Some would say that using an Agile approach, such as Scrum would be a better approach. Taking an Agile scheduling approach is definitely valuable. But the idea that there is no understanding of the full scope can scare some. When taxpayers or investors are funding your project, you have a fiduciary responsibility to ensure that the outcomes are worth the investment. Even in this divided world, we can probably agree that a half-built bridge across the Mississippi is pretty worthless.
Can we have an Agile execution and still have a defined scope that is well managed? It takes some work, but I believe you can. Here are some recommendations for managing project scope while achieving agility.
Define the scope inclusions AND exclusions.
Sometimes defining what you are not going to do is more important than knowing what you are going to do. Just understanding which sandbox you are supposed to be playing in can solve a lot of problems on the playground.
Sometimes defining what you are not going to do is more important than knowing what you are going… Click To Tweet
Use just in time planning.
Determine whether you want to plan out the work in phases, and if so, focus on defining all of the phases and then, just plan out the first one. Some projects need to be planned out more fully from the beginning. Others lend themselves to a phased approach. If you are working on a project that needs to be planned in phases, try to get a general understanding of each phase, and then, plan out the first one well.
Use a visual work breakdown structure.
I recommend a visual work breakdown structure. For most of us, a picture is worth a thousand words. If you don’t know how to do this, read this blog. The key here is to identify the essential activities and to clearly define what ‘done’ looks like. Don’t try to identify every phone call, document review, or experiment that needs to be done. There will be time for that, but at this point, the goal is to break the project down far enough that you can estimate the cost. Will the activity take one person a day or five people three weeks? Who will do the work? Who will be in charge of each activity? What kind of quality is needed on each activity? Are there any risks or issues?
Engage the team on budget conversations.
Make it a responsibility of the team to create and then, live within the budget. Use your work breakdown structure and estimate a cost for each of the essential activities. Estimate higher when there are more unknowns to keep the client from being blind-sided. Encourage the team members to scream loudly and quickly when there is a problem. Most clients are pretty reasonable when they understand the unknowns.
Work in sprints or short blocks of time where you focus on a specific batch of work.
I typically recommend that teams work in two-week blocks of time, and during that time, stay focused on a selected group of activities. Resist the urge to spread yourselves so thinly that you don’t finish the work that you have designated for that sprint. On a quickly moving project, you may want to move to one-week sprints, and if the project doesn’t need speed, perhaps you go with three or even four-week sprints.
In traditional Scrum, the length of the sprint (and the size of the team) is kept constant so that productivity metrics can be developed, monitored, and used as a tool for improvement. This is great when it works, but I see a lot of projects, which for valid reasons, simply cannot be managed that way. But that doesn’t mean that you can’t still work in sprints. You can!
Focus on delivering value at the end of each sprint. Meet with your client at the end of every sprint (or two) and review the value produced and get feedback. This is especially important when you have organizational change projects where you need to slowly bring a team of people around to a different way of operating.
There may be times when meeting with the client every other sprint is preferable, especially if your client representatives are corporate executives. You may need to move in two-week sprints to keep the team engaged, but you may need more time to prepare enough value that busy executives are ready to meet.
Use the end of each sprint to plan the work that is to be done in the next sprint.
During each sprint, you should stay highly focused on finishing the work that you selected. At the end of every sprint, you will review what you have accomplished and identify the next items of work. You need to get commitment from the people who have been selected to do the work during the next sprint that they are available. Focus on getting a commitment to delivering the work, rather than getting a commitment to being available.
I find it helpful to think about this as looking forward at the same time as you are looking backwards. You look to the past to see what has worked, what hasn’t, and why. You use that information to plan for the future.
Does this make sense? I routinely hear that Agile folks and traditional folks don’t talk to each other. I hope that isn’t true, because both sides have a lot of value to add to the conversation. If I can help, sign up for a free call.
