I recently met with a project team that was trying to become more Agile but they didn’t really know what that might look like for them. We got into a discussion of their software — which allows them to select a Waterfall or Agile approach — and then, the software presents the appropriate interface. But everything seemed so complicated to them.
There are many blogs, books, webinars, and courses that anyone can take to better understand the important parts of project management. But all of that takes time — and for many, time is in short supply. That means perhaps we should look to simplify project management.
I’ve met with many project managers who disagree with me on this. Most project managers will argue that simplifying project management would mean we can’t justify our salaries. I respectfully disagree. If we simplify project management, and stop wasting time on things that don’t work, we’re then free to work on what is most important — and what will produce the greatest value for the organization. If we simplify project management, we can attract project managers with some people skills instead of brainiacs who prefer to sit behind a desk and juggle reports.
So, what should we be working on? I recommend that we focus on starting our projects well, building highly effective teams, frequently delivering value to the client (or the management team), managing costs, risks, issues, and other project details, and actually learning lessons from the work we’re doing. If we did all of that well, our project successes would greatly improve, and that would justify the salaries.
Here are eight ways that we could simplify project management. I’m not saying it will be easy. I’m saying that we should focus on what’s important and what works, instead of spending time on unnecessary earned value reporting, critical path diagrams, and Monte Carlo simulations. It’s not that those sophisticated techniques don’t have their place, but for most projects, we just need to create fully engaged teams that are working at peak efficiency and effectiveness.
Use a common language.
I just wrote a blog on that last week, so I won’t belabor this point.
Set up your project to regularly deliver incremental value to the client (or management).
Regardless of whether you use Waterfall or Agile, you can focus on delivering value. While I’m not a great fan of the word deliverables, it does mean something specific to most people in the business world. It’s easy to think up a list of tasks that you are going to do in order to complete a project. But think of it differently. Translate those tasks into something of value that you plan to deliver to the client (or to management). You’ll still have a list of tasks that you need to do, but your focus will be on delivering value to the client.
I’ve written before on how to break down (or decompose) a project. If you get this right, the rest is easier. After you break the project down, then focus on which activities will deliver the highest value to the customer. There may be many things that you have to accomplish before the highest value activity can be done, but that’s the direction you want to go in. What can you do today which will offer the most value? Do that next.
Work in sprints.
It doesn’t matter what you call it. Some people refer to it as time boxing. The point is to focus intently on a discrete set of activities and finish them in a particular time frame. In Waterfall, we talk about estimated percent complete. And we create reports that tell us how far along all of the activities are. But in a world where activities often go through multiple human reviews, estimating percent complete is flawed. A partially completed deliverable has no real value. We need to focus on getting things done. And that means understanding what done means. So often, I see teams spreading themselves thinly, and taking forever to finish things. Focus.
Put aside the need for a schedule and identify the critical deadlines.
Not all deadlines are equal. Know what the critical deadlines are and meet them. No excuses. Let the other deadlines guide you but don’t beat people up for missing them — they are just targets — not critical deadlines. If you’re extremely focused in your sprints and delivering value to clients every week, you may not need many dealines. But some people work better if you give them a deadline.
Speak and write effectively.
Technology has dramatically changed the way we communicate and in some cases made our conversations barely understandable. From numerous acronyms that are often not understood, to words with multiple meanings (like Agile and agile), to nouns that have been turned into verbs. And then there’s the difficulty that some Waterfall people still have in communicating with Agile proponents, and vice versa. I read a satirical blog post recently about the things that people could do to make themselves look smarter during meetings. One of which was to turn everything into a acronym. It was pretty funny — and also sad because I know people who actually do all of these things in meetings.
The same is true of our writings. As we add more words to our emails, executive summaries, presentations, or other writings, we need to ask ourselves whether we’ve made the issue simpler, or just confused the matter.
I think the KISS method of communicating that some of us learned in middle school — Keep It Simple, Stupid — may have value these days.
Build a culture of trust.
There are many opinions on standing meetings. I’m just not sure there are many substitutes for facing each other periodically and committing to do something. It builds accountability.
Having a regular time when people are expected to open up about problems is healthy. Hiding problems creates stress for the people who are hiding the problem, and for the people who will ultimately be involved when the problem finally surfaces. Problems are not like fine wines. They don’t usually get better with age.
I understand that a daily standing meeting may not be needed on every project. And when individuals are working on multiple project teams, the time spent in daily standing meetings may not be smart. It depends on how fast a project is moving.
I think the key here is to build a culture of trust and support. Hire people with high emotional intelligence and it will be easier.
Celebrating small wins.
I was talking with a project team recently and someone asked me about shout-outs. One person seemed rather surprised when I said I’m a big fan of giving shout-outs to people. I’d stop spending time on a bunch of reports that no one is looking at (if you can do that) and stop and say thanks and mean it. Celebrate your small wins. Drive momentum. Keep people energized and excited. You will still need to do some reporting, and some management oversight. I understand that. But put your focus on keeping the team going. If the team is making progress, the report may be obsolete before anyone reads it. That’s really not such a bad thing. When we can build teams that want to get to done faster and more effectively, everyone benefits.
Manage the big details.
Projects have a slew of details. It can be easy to think that if we are chugging along towards the destination that we can skip the rest. But I still recommend that you have a process for managing the costs, risks, issues, and other project details — from start to finish.
If you need some help, give me a call. Sign up for my newsletter if you are looking for ideas. I try to review a new book every week..