Complex projects are often described as ambiguous projects. They differ from complicated projects in the way they emerge. One set of activities gives rise to another set, which cannot be predicted until people have seen how the previous set of activities plays out.
There can be varying reasons for this emergence phenomenon. It may be a research product, where scientists have to ascertain the results from a certain set of experiments. Or, it may be a change project, where leadership needs to become comfortable with the recommendations that have come out of one set of activities. Regardless of the reasons, dealing with project ambiguity can be hard for some.
Here are eight tips for dealing with project ambiguity.
1. Focus on the why.
Regular readers know that this is not a new concept. And yet, it is so easily forgotten. Focusing on why starts with understanding the end game. Begin to focus on what big accomplishments are needed before you can achieve your end game. While knowing your why begins with an overall vision, try to understand the why behind the different project pieces too.
Scrum practitioners do this really well in the way they write user stories. While user stories have the potential to focus us on the granular stories, rather than the main objective, I still think the practice of looking at why is important. To read more about user stories, see this blog.
2. Distinguish between activities and tasks.
Planning ambiguous projects is hard because no one on the team can predict the future. So, planning is challenging. Begin with what you know. Identify the essential work packages needed to accomplish those activities. Think of each of these work packages as something that you can deliver to your client or to your management team. Don’t get bogged down with trying to identify every single phone call or document review. Look at the work packages from the perspective of your client or your management team and try to deliver some incremental value. Fill in the details later.
3. Use time-blocking to schedule the work.
Before each time-block (some people call these sprints), identify the work that will be done. When people struggle, it is often because they don’t understand the task. Some people are better at thinking about how to take the ambiguous and make it clearer than others.
Help everyone on the team understand how he or she can help. That means really documenting what every work package entails. Is that report that you are delivering supposed to be a ‘pdf’ document with absolutely no errors, or a Google draft doc for further editing? Are you supposed to include supporting schedules in an editable spreadsheet or simply pictures of the final result tables?
Plan the length of your time-blocks around the speed of work. On some projects, you will need to move quite quickly and will be meeting weekly for the purpose of planning the future. In other projects, monthly may work. And, unlike software development projects, the length of your time-blocks may shrink or expand, as project needs change.
4. Plan ahead/look backwards – focus on the big picture.
Meet at the end of every time-block to plan for the future. During these meetings, review the past, celebrate accomplishments, and document the lessons learned. Then, identify the activities for the next time-block.
5. On ambiguous projects, let teams manage the how.
If you are part of the management team, resist the urge to tell the team how to do the work. There is a difference between setting clear expectations and micro-managing your team.
6. Consider the benefits of transparency to help with project ambiguity.
There is great debate about transparency in online tools. How much information should the client be given? How much information should management be given? We’ve all heard stories of team members who were embarrassed to disclose that they were behind, or hadn’t done some crucial task. And then, the entire project failed to finish on schedule. Building a culture of accountability means promoting honesty and transparency.
Dr. Louise Comfort, Professor of Public and International Affairs at the University of Pittsburgh, believes that “the key to fostering successful emergence and complex behaviors is to increase transparency—the ability of participants to share relevant information.”[i]
7. Consider the idea of exploratory projects.
I’ve been exploring the idea of exploratory projects lately, and there may be companies and situations that warrant an expenditure of time and money to explore a scenario, perhaps indefinitely. But that’s not technically a project since it has no ending.
Startups are frequently in a place where they are constantly executing a set of activities, learning from that experience, and then moving to another set of activities. It can feel like a project, but there is no ending and no approved budget.
Some Agile proponents would argue that the terms project and management are anachronistic and that we should move into the 21st century, where rapid change and complex thinking has changed the way we work.
8. Have a process for scope management to avoid project ambiguity.
For most companies and governments, there will still be times when it is appropriate to have a defined scope, budget, and completion date. In those cases, we need a process for scope management – even if those projects have some ambiguity. Otherwise we have little chance of being successful.
Scope management begins with knowing what you are doing, and what you are not doing. Add to that a budget for each activity. Then identify the critical deadlines. I’m not a huge fan of putting a deadline on each activity, though some people prefer to work that way. Designating some deadlines as target deadlines, and some as fixed deadlines ensures that you don’t miss what’s important.
Then define a change management process. Having a committee of people who can approve changes can take some pressure off of any one person. While change may be the new normal, following a change management process can keep chaos from being your normal. Are you struggling with project ambiguity? Perhaps I can help you. Give me a call.
[i] https://www.businessofgovernment.org/sites/default/files/JohnKamensky.pdf, p. 68