As those who know me well know, I have a love-hate relationship with project management. On the one hand, I love the planning, and watching a plan come together. On the other hand, I’m frustrated by project teams that aren’t run well and have pulled my hair out for years over the available tools and how project managers use them. I just can’t understand why we’re spending so much time on scheduling, and an insufficient amount of time motivating the people who are doing the project. There are many factors complicating project management.
On a recent LinkedIn thread, there was a posting about start to finish dependencies and when to use them. The new PMBOK guide is about 975 pages and is not easy to read. Volumes have been written about earned value management. And then, there is the reality that we are using Agile on some projects and Waterfall on others. Is any of this actually improving project performance? I have struggled with this question for years.
What do we really need to run successful projects? We need effective and committed teams, strong sponsor support, some form of portfolio insights so that we don’t misdirect efforts, and a clear vision for the projects we undertake.
In this blog, I’ll ask some questions that are designed to get people to think about why we should stop complicating project management.
Do we really need earned value management?
For the uninitiated, earned value management (EVM) is a complicated project management technique for measuring what we’ve actually done against what the work has actually cost. It looks at the intersection of scope, schedule, and costs.
Wikipedia defines EVM as “a project management technique for measuring project performance and progress in an objective manner.” The phrase objective manner caught my eye. I have written before on why I believe EVM is a flawed concept in a world where work is done by knowledge workers, rather than machines. In a world where estimates are done by people, often people who don’t want to look bad in front of the boss, I’m rather surprised at Wikipedia’s claim of objectivity. How can we really say that EVM produces an objective measurement?
I completely understand that we need ways to measure progress; we need to know what is happening to our scope, schedule, and costs. But is earned value the best approach?
Do we really need to designate dependencies on all activities?
If you want to create a Gantt chart, you assign dependencies so the software can do the work. Otherwise, all of your activities will start at the same time. There are four different kinds of dependencies:
Finish-to-start dependencies (FS)
– The next activity cannot start until after the preceding activity finishes. (You can’t decorate your holiday tree until you have put the tree up.) This is the most common type of dependency.
Start-to-start dependencies (SS)
– The next activity cannot start until after the preceding activity starts. (You can’t start putting ornaments on the tree until you start bringing the boxes of ornaments down from the attic. But note – you don’t have to finish bringing the boxes down before you start putting some on the tree.)
Finish-to-finish dependencies (FF)
– The next activity cannot finish until the preceding activity has finished. (All gifts must be bought and received before the wrapping can be finished.)
Start-to-finish dependencies (SF)
– The next activity cannot finish before the preceding one starts. (You cannot finish mailing your holiday cards before you start editing your mailing list. And as some know, you may still be editing your list when the cards with bad addresses come back.) This is the rarest type of dependency.
Now that I’ve outlined the four kinds of dependencies, can you see how complicated it can get? Does it really matter? Yes, I tried to illustrate this with a simple project. Business projects are likely going to be much more complicated. My concern is that this focus on assigning dependencies is a distraction from really understanding what is happening. And, think about how easy it is to make a clerical error and put the wrong dependency into your project software – and suddenly that schedule is not really what you need.
What is much more important than setting up these dependencies is to really understand the activities and how they relate to one another. Who is doing each one? Are there materials, supplies, or other needs that are important for particular activities? Which ones have critical deadlines? What other demands are on the members of the project team that could interfere with an important deadline?
Do we really need to complicate conversations with lingo and acronyms?
Periodically, I will meet with a new team about a project problem and I’m astounded at the amount of lingo that continues to creep into our conversations. To some extent, this helps teams who work together frequently use short-hand in their conversations, as the list below illustrates. But all of these acronyms can have different meanings in different contexts. And when someone new comes on board, it can slow down understanding.
- SME – subject matter expert, small-to-medium enterprise, system management entity
- PM – project management, portfolio management, project manager, program manager
- CCB – change control board, configuration control board, customer care and billing
- CV – cost variance, Curriculum Vitae, constant velocity
In addition to acronyms, we also have confusion over the way words are interpreted in a Waterfall environment versus an Agile world.
The simple word “activity” can have different meanings in different projects. For example, it might represent a work package or a group of related tasks in one project; or it might refer to every task that needs to be done in another project.
In one project, we might talk about a requirements document while in another, we might talk about a scope statement or a user story.
Change is a dirty word with some teams while it’s embraced by others. I’ve written before about why we need to find a simpler project language.
If you are struggling and need some coaching, give me a call.
