Ever had one of those projects where you were tempted to skip best practices, the usual processes and templates and just do it your way to get it done? It may be a very short term project, a very low dollar project, a project flying way under the radar, a project where the customer is saying, “Let’s get this done NOW!”, or maybe it’s an issue-riddled project and you’re just trying to shove a working version out the door so you can get it signed off. Do any of these scenarios sound familiar?
For whatever reason, the project didn’t seem to warrant the attention to detail, the frequent status reporting and oversight warranted by normal project management best practices. Risks??? What risks? Resource planning? It’s not going to last that long…so why go into detail? Budget forecasting? It’s a small budget on a straightforward project so…um…why bother? Creating and tracking a detailed schedule through project management software – why bother on such a short-term project? All we’re doing is fixing and testing issues to get to rollout – why follow any best practices…we need speed and resolution! Have any of these phrases been uttered by you or a colleague only to have them come back and bite you later on?
Why best practices matter
Here’s the deal…best practices are best practices. And however you or your organization defines best practices is up to you – but the bottom line is they are what you have determined to be the benchmark by which you manage your projects and provide your customers with the best effort possible. At the same time you’re trying to give yourself the best chance at project success…which is no small undertaking. More than 50% of all projects fail to some degree or another – so why not take any edge you can get?
Cutting corners
The truth is…I’ve been there. And I probably will be tempted to go there again. I’ve taken over a problem project to get through software issues on the way to deployment. I had my team in all-hands-on-deck mode with everyone working extra hours to resolve all of the outstanding issues. Suddenly, I found out the customer was frustrated not with the issues (they were, but that was an ongoing frustration) but they were now frustrated with me for not holding regular weekly status calls and producing weekly status reports. Calls were sporadic and reports – other than the detailed issues list I created that we were all working off of – were non-existent. I wasn’t even using a project management software tool to produce revised schedules – I just didn’t see the point given the tasks my team and I were performing. I learned my lesson the hard way.
Once I started revising and delivering a weekly project schedule and producing a weekly status report and holding regularly scheduled project status calls instead of the adhoc calls that had become the norm then I started to see customer confidence and satisfaction rise. I also noticed that the team fell in line better – we became better organized and getting through the remaining issues became a smoother process.
Going back to what’s important
The bottom line is that all of those repetitive little things that we do on projects are more than just little things. They are consistent behavior, they are customer confidence boosters, they are tracking devices that we sometimes don’t even realize we need until the project goes off track, and they are a nice accountability factor for us as project managers to our team, our client, and our senior company leadership.
All the up front planning we do creates a solid foundation of planning documents, reference materials and finalized requirements that then become building blocks for success on the rest of the project. The consistent delivery of status reports and revised project schedules from our project management software build customer satisfaction and confidence that isn’t always that easy to gain and it can be very easy to lose. And consistency in how and when we hold status discussions with the customer and our team sets a foundation for cohesive teamwork and collaboration for the entire engagement – especially if we’re dedicated enough to practice it from beginning to end and not forced to regroup and initiate this behavior midway as corrective action on a floundering project.
Summary / call for feedback
How about our readers? Have you found yourself in a position of being pushed to get things done now – forcing you to abandon your usual project management methods? Did you succumb to the pressure? What was the outcome?
