This is a question I am often asked by the young professionals I try to help develop their career.
And it’s an important one, because unless someone is proficient in delivering results in their current position they won’t likely get serious consideration for other opportunities to advance.
They can’t understand why results aren’t forthcoming — they can’t deliver what’s expected nor are they able to meet the deadlines imposed on them. And yet they put in countless hours on their projects and they feel they work harder than their peers.
Throughout my career I was assigned project after project with numerous objectives, and learned how to consistently complete each one of them on time and on budget.
These 6 factors I learned were critical risks to the success of any project.
I can’t hear anything
There is so much noise and clutter out there waiting to distract you from your prime purpose. A text from a friend or colleague to help them out with a project they are working on or a request from your boss to take care of something that suddenly came up.
Over-the-transom activities that you get pulled towards that redirect your attention and consume time that otherwise could be spent on your project.
Project success comes from being focused on what you have been asked to deliver, which means filtering out the stuff — the smoke — that will divert you.
Who’s my customer?
Quite often it is unclear who the main client — the project acceptor — for the project is. Or there may be a number of stakeholders and the primary one isn’t defined for you.
The result is that you are dragged in a number of directions due to the different interests and agendas of the various interest groups.
To successfully complete a project, the acceptor of the deliverables must be defined and agreed upon before the project work begins; never launch into action before this is done.
And get it in writing. I always had a terms of reference document prepared for every project I was assigned, and an integral component was the signature of the project acceptor (as well the signatures of other stakeholders who agreed to provide support to the project but recognized who the owner of the results was).
Lack of senior ownership of the project results will not only jeopardize the results, it also provides others with the opportunity to blame the project manager if results don’t meet expectations.
I can do this myself
Sometimes there is a tendency to try and do it all yourself rather than reach out and take advantage of the expertise and interests of those around you. After all, it’s time consuming negotiating with others what their specific role will be and it’s a sensitive matter when you are in a position of attributing the good results of the project to your peers and colleagues as opposed to receiving all the glory yourself.
Very early on in my life as a project leader I realized that success only comes through engaging others — it needs to be a team effort.
My blueprint for any project was to get the brightest and the best on your team, help them play their role and lavish them with praise when they delivered what they promised.
You want me to do what?
The expected output of the project must be specific and granular; lack of clarity generally means the project is dying from its launch.
Roy’s premise: the success and value of any project is directly related to the specificity of the expected outcomes.
So spend the time upfront with the project acceptor on EXACTLY what constitutes success — specific deliverables and timeframes.
Document these in the project terms of reference and have them signed as agreed upon by both you and your acceptor.
If this work isn’t done well enough at the start of a project, generally what happens is that acceptable deliverables are defined (and revised) on the run as the project is in motion.
The result: the project team is run around wasting their efforts, the acceptor is not satisfied because they’re not seeing the results they want (but didn’t identify accurately up front) and the project team takes the hit.
What does my text book say?
When I began doing project work, I relied on my education for guidance on how the problem should be approached and what the appropriate solution could be. I dug out my text books on statistics, probability theory, economics and business planning and tried to pull from them any insights that would help me derive the right solution to the problem I was given.
To a young professional just starting their career in business, this was the only way to attack the challenge I was given, as specific direction from a project acceptor on HOW to proceed was rarely handed out — you had to figure it out yourself.
What I learned a few years in to project work, however, was that success — defined by outcomes that could actually be implemented in the organization — was more a function of CULTURE than theory.
In other words, I discovered that results that were grounded in solid academic theory didn’t work if the people in the organization didn’t accept them as having any personal benefits. The best result “on paper” I learned was not a solution at all if it ignored the cultural context of the organization.
So my project approach changed to one which took into consideration what good theory suggested, but which concentrated on finding a solution that fit the culture of the people in the organization that has to live with it.
This process worked amazingly well because the receivers of the project outcomes not only understood the solution proposed, they embraced its implementation because it benefited them personally and as an employee group.
What should I do when things go off track?
A project never turns out the way it was originally intended; it’s an amoebic “beast” that is always under pressure to morph to a different form.
The organizational environment changes, internal policies change, markets change, customer demand changes, competitors attack and project team members move on.
Even though you did the right thing and developed a signed terms of reference document for your project, things will happen during the course of your work that will change your agreement in some way.
And when this happens, the wrong action is to stay the course; stick to the original project plan even though you know the changes that have occurred are significant enough to warrant a project “time out”.
The right action IS to take a time out and review the project in its entirety — intent, expected outcomes, team membership, ownership and timeframes — and reset the terms of reference for your work.
A successful project is one which produces value to the organization in the current set of circumstances it faces; when those circumstances change the project must as well if it is to succeed.
Perhaps there are other reasons why certain projects succeed — luck and serendipity perhaps — but if you manage to address these 6 factors, your performance dashboard will show many more winners than you could have imagined.