It might be stating the obvious when I say that project team members should be motivated to achieve project success. In this blog post I offer up some suggestions how to guide a team so they can meet this expectation.
Awareness of Organizational Inertia & Habit
Organizations can become overly bureaucratic and unintentionally create layers of management and processes that probably seemed like a good idea at the time, but over time have morphed into something quite different. Once these get embedded in company culture it’s not easy to break habits and stop “busy” work and focus on business goals. Sometimes a reminder is needed about expectations.
I think a similar view is needed on projects: the focus of your time should be spent on tasks that move the project forward. You need to carefully examine your role and activities and be able to draw a direct link between what you do every day and the project goals. Something is amiss if you can’t make this connection in a simple fashion or it’s a convoluted path to make the join.
Work with Intent: Deliverables, Details and Decisions
Fortunately thinking about deliverables, details and decisions can help bring intent and show the connections between actions and project goals.
Deliverables
Any project methodology – and to a certain extent I don’t care which one – requires creation of deliverables. These artifacts should build together in a way that helps deliver the project, but a key thing to remember here is that a deliverable template in and of itself is of limited value. For example, a project that requires a set of technical specifications can check the box if the project produces that set of documents but the real value is in the content of those documents. The template serves as a guide and a prompt for the information that brings the value.
Each project has a plethora of deliverables and for each one the details within are what count.
Details
Somewhere in popular culture a feeling arose that computers sometimes do what they want and they don’t cooperate. The idea of sentience and that a machine is just messing with you is not true – OK, I’ll accept some leeway on that for folks working on AI, but for business applications used by regular folks it’s not the case.
That “messing with you” behavior is because someone design it and coded it that way. The details of how a process works at the lowest level is required in a project and all the low level parts of the design must come together to create a coherent solution. Specificity at a granular level is essential because code is unforgiving.
Continuing my example of a technical specification, I can imagine an interface mapping description that says to take the fields on an output file from a source system and map them into the corresponding fields in an input file for a target system. There’s a lot of assumed knowledge and processing in that statement and it’s certainly not explicitly clear what is supposed to happen in this interface. Detailed work requires examining and describing what should happen for each input field or combination of input fields, what transformations are needed, and so on. A deliverable template can guide you on what you need to capture, but it won’t do the detailed thinking and describe the processing for you. Implicit in this is decision making.
Decisions
Throughout a project everyone is making decisions of widely varying impact. Project scope decisions can be huge, choosing a text font for a standard output form can be minor. Nonetheless decisions are required and everyone needs to be comfortable making them, sharing them and moving on to the next one.
Back in the example of the interface technical specification getting the details about field mappings requires making decisions about field usage and business rules. Discussion, thought and analysis go into the decisions that move the project forward.
Driving towards decisions will force details that are captured in deliverables. In theory, and who doesn’t love some theory, it’s pretty straightforward. The real world acts differently.
Asymptotic Completion / Analysis Paralysis
There’s a gut feeling truth to the 80/20 rule where 20% of the work takes 80% of the time. I’ve worked on projects where deliverable status tracking shows rapid progress from zero to 70% to 80% completion and then a slow uptick to 90% completion. Then deliverables seem to sit at 90% completion indefinitely. It’s as though Zeno’s paradox has come to life and the final 10% can never be finished.
The apparent inability to complete deliverables is always grounded in something – changing scope, new requirements, new information, snow storms, traffic delays, lousy internet connections. Yet the world is full of functioning devices: automobiles, refrigerators, operating systems, automated checkout lines, to name a few. How does this happen?
The simple answer is that decisions were made that stopped the endless analysis, second guessing and refinement. I’m sure not every possible scenario was considered; compromises and trade-offs were made. Someone stepped in, drew a line and said enough. You can be that person.
Progress versus Perfection
Most projects I’ve been on come up with a variation of don’t let great be the enemy of the good once they see the way the final 10% of a deliverable eats into their timeline and budget. I believe working with positive intent is a way to make meaningful progress and create high quality deliverables. Communicating ways to approach their work and giving them the power to stop at an 80% to 90% solution has the potential to preserve timelines and budgets and bring a strong sense of accomplishment to project teams.
Positive intent – try it, you might like it.