According to the Standish Group’s 2015 Chaos Report, I have a 64-percent chance of guessing you’ve been on a challenged or failed software project. According to the Chaos Report, only 36 percent of all projects have been successful while others were challenged or failed to meet the business objectives. I’ve seen a lot of projects that were challenged and some that have even failed.
Do any of these situations sound familiar?
- The team doesn’t know the detailed project timeline.
- The team doesn’t have all the requirements.
- Team members are going off in different directions.
- “Project heroes” emerge, trying to be the sole project savior only the realize one person can’t change the entire project.
- Communication is a mess, and it isn’t clear what people are doing in specific meetings.
I’ve seen a lot of these situations, and project teams continue to spin, failing to make progress while the calendar slips by day after day. I’ve even caught a few of the projects in my portfolio going off the rails; however, I’ve always found that, when a project is in trouble, the team needs to return to project management fundamentals.
Return to Project Management Fundamentals
The good ol’ Project Triangle—scope, time, and cost—is the perfect reference point for project fundamentals. From our PM training, the Project Triangle is also referred to as the Triple Constraint. If you change one of the sides of the Triple Constraint, the other two constraints need to adjust.
Project managers can examine their project using the Triple Constraint and evaluate how well the project is performing. The PM can make improvement recommendations by examining each constraint.
Is there a work-breakdown structure (WBS), scope statement, or a product backlog that defines the project scope? If the scope isn’t well defined, it becomes difficult to understand how the project is organized.
With the popularity of Agile, project teams will question a WBS. However, a product backlog composed of epics and user stories is a WBS (albeit a very deep, vertical one). Story maps, backlogs, and a set of epics all define the work and project scope.
I love Agile delivery but don’t let team members use Agile as an excuse for not understanding the major workstreams and deliverables for a project. If there isn’t a backlog or a WBS, I spend a few days creating one and validate the scope statement.
The project timeline is a key project management artifact that will help measure and communicate projects. Ask the project team the following questions:
- How are you tracking against your original commitments?
- How do you know if you can meet the delivery date?
- What measurable data (completed tasks, completed user stories) provide confidence in reaching the project end date?
I had a meeting with one executive and asked, “How do you know the team is on track?”
He replied, “I know they are because I trust them.”
I asked, “What schedule, burn-down chart, or milestone chart gives you that confidence?”
He responded, “You’re right. I need them to demonstrate they are on track.”
Team leaders need to trust their teams, but they also need evidence of real progress. Otherwise, project status reporting is in the green week after week and then suddenly a few days before launch—RED!
When applying the Time fundamental, build a schedule, track against the schedule, and revise the schedule as the project progresses. You need to communicate the schedule progress, but tracking against commitments will help turn the project around.
If this is an Agile project, build the release plan and start mapping features into sprints. Even if you’re Agile, you will still have external integration points with finish-to-start dependencies. Just because your Agile, doesn’t mean you can’t have other traditional PM tools to help with communication and planning.
If the project team has scope and time defined, the resource will identify who is doing what in your project. Troubled projects often have redundant resources working on the same tasks as each team member tries to play the project superhero and do it all.
My quick fix is to assign resources by workstream, which is usually the major chunks of a WBS. Within each workstream, it is important to understand who is doing what and define the “gives and gets” across workstreams.
The responsibility assignment matrix or RACI chart are traditional tools that help define resource expectations. Project teams risk skipping this tool, and even though it is administrative, it is very helpful to align resources in a project.
Assess the Management Style
Assessing the project management plan is the next step to fixing a troubled project with fundamentals. Every project needs a project management plan. This isn’t a schedule. It is a collection of the PM processes used to manage the project.
A good project management plan should address the following:
- Integration management: How will all these workstreams and team members come together?
- Communication management: How will we communicate with all our stakeholders?
- Scope and change management: How will the scope be managed?
- Time management: How will project schedule updates be managed?
- Cost management: How will the financials be managed?
- Issue and risk management: How will issues and risks be recorded and managed?
- Quality management: What is the plan for quality?
- Resource management: How will resources be hired and trained?
- Configuration management: Where will all our project documentation be stored?
- Vendor/procurement management: If applicable, how will vendors and contracts be managed?
This doesn’t have to be a lengthy document that no one will read. It can be easily developed and communicated in a PowerPoint presentation or project kickoff presentation.
Focus on the Fundamentals
If you find yourself with a struggling project, return to the fundamentals and verify how the sides of the Project Triangle are being managed. If your team members understand the scope, their role, the timeline, and the way the project will be managed, you’ll be surprised at how well the project will improve.