4 Fallacies of Typical Project Management Thinking
I have spent over a decade managing projects and studying different philosophies on what the best practices for this are.
During this time, I have managed many successful projects, several unsuccessful ones and obtained the Project Management Professional (PMP) and Certified Scrum Master (CSM) certifications.
As I continue to study the profession and see what works and what does not, I’ve found that many project managers are trying to force rules from a textbook into every project that they manage. They are using certain techniques that are generally acceptable for many projects but should not apply to the ones they are managing – hampering their ability to successfully bring the project to a conclusion.
While the methods they are trying to apply are proven to work with other projects, they cannot be viewed as the optimal methods for every project. Each project has its own nuisances and needs to be managed differently. These are several common philosophies that I see project managers trying to force on every project when a different approach would be better.
#1 – The Weekly Status Meeting
Few things in project management seem as sacred as the weekly status meeting with the customer. For the first part of my career, my managers insisted on it and I would reliably run these meetings without fail. However, when I was assigned to a new manager, he challenged my thinking and started asking me about the real effectiveness of those meetings. As I analyzed these status updates, I realized that the meetings I was running were not a very good use of everyone’s time.
For starters, meetings in general are increasingly under scrutiny by companies trying to get more out of their employees. Attentiv, a company dedicated to studying meetings to offer solutions to make them more effective, found that 63% of meetings take place without a pre-planned agenda and therefore, meeting participants feel that 33% of meeting time is unproductive.
In looking at the meetings I was running, I realized that mine were falling into this trap of not being planned out well or being effective. To correct this, I made it my goal to ensure that every meeting had an objective and agenda associated with it.
Interestingly enough though, as I tried coming up with an objective and agenda for the weekly status meetings, I found that for the most part, I could not come up with anything that would justify pulling multiple people away from their jobs. The content of the status meetings was typically updates on open items and project milestones.
By typing those statuses up to prepare the agenda, I realized that by sending that status update, I would have fulfilled the objective of the meeting. That is when I switched gears and stopped holding weekly status meetings but rather sent out status updates. This fulfilled the objective of keeping all the stakeholders aware of where the project was at without needing to take up more of their time on a meeting.
Initially, a few of my customers balked at the idea of not having a weekly status meeting. They too had it engrained in their thinking that the only way to manage a project was to meet weekly. But after several weeks of getting the email with project status updates, they agreed that it was a much better way to manage the project.
If you feel like you are spending too much time meeting with the stakeholders on projects you manage, I would encourage you to build a status report template that gives all the pertinent information in it (which you would have to gather anyway to prepare for a status meeting) and send that to the stakeholders in lieu of the status meeting.
#2 – Setting a Go Live Date
After spending over a decade working on software deployments, the first question I get from the customers when a new project is started is when they will be live on the software in a production environment. I understand the reasoning behind this as the company has just invested a lot of money into the software solution and want to know when they can start seeing some ROI.
Here is where the project manager will play a pivotal role in setting the correct expectations for the successful completion of the project. I have seen too often that project managers will provide new customers with a go live date at the very beginning of the project. If that date is not met, it will often lead to disappointment with the customer and have the potential to sour the vendor/customer relationship.
In order to avoid this, I tell the customer that I cannot give them an exact date that early on in the project. I let them know that there are too many variables that are yet unknown before committing to a project conclusion. Since the software I have implemented has always been very configurable for a variety of operational needs, I stress to the customer that my team of consultants need to first meet with them to understand unique business requirements before knowing when the project will realistically finish.
In the book Implementing Lean Software Development by Mary and Tom Poppendieck, they discuss deferring commitment, one of the seven principles of lean thinking. In the book they are quoted as saying “in the face of uncertainty especially when it is accompanied by complexity, the more successful approach is to tackle tough problems by experimenting with various solutions, leaving critical options open until a decision must be made”. I have applied this principle to complex software implementations where ending go live dates are being asked for prior to having all of the information needed to fully develop the solution.
During the business requirement gathering, I stress with my team to not only be looking for their operational needs to see how well they will fit into the core of the software, but also into the customer’s project team makeup. Having a customer with complex system needs that may have to be customized will certainly extend out a project timeline. However, even if their requirements are simple, if they do not have a competent project team with high level organizational backing, the project will probably also lag.
That is why, only when the business definition sessions are finished and me and my team can fully analyze both the customer’s requirements and project team makeup, will I ever try to determine an end date for the project. I can remember one customer that as we went through the project definition process we uncovered many usability gaps and they had to spend more on customizations to the software than they did on the original software package. That project took much longer than a typical implementation.
Too many project managers commit to a deployment date very early on when they lack the full knowledge needed to make an informed decision. Most of the time, the dates that are chosen are ones with the best case scenario in mind – a customer with straightforward needs and a dedicated project team. By doing this, those project managers are setting the stage for problems in the future. If that customer’s project will be very complex or they do not have a team with a lot of dedicated time, it will require much more time than a standard implementation.
Rather than giving the customer unrealistic expectations before knowing all the variables that could impact the project outcome, project managers need to tell their customers that they will only be able to provide them with a project timeline with estimated go live date after the team has been able to analyze the customer business processes and team. Then when you are able to come up with a schedule, everyone involved will have a lot more confidence in being able to successfully go live in the agreed upon timeframe.
#3 – Providing a Very Detailed Schedule
A day does not go by as I’m reading the news that I do not come across a story of a project that is called out for being significantly overdue. Headlines like “the project was scheduled to be completed on January 15 and now it is months late” give readers the impression that the project team is not doing their job.
When I read stories like this, I can empathize with the project managers because I’ve been a part of my fair share of project like this in the past. I would set a very detailed schedule with exact dates like January 15 or October 3 and then when the project moved past those dates, there was a sense of failure for not finishing on time.
What I have learned in that setting of exact dates – especially ones that are far into the future – is risky for project managers to do. One thing that happens when an exact date is given is that it can be marked on calendars and if the project goes past that date, it is very obvious that a date was missed which paints the project manager and project team in a negative light.
The way I have been able to avoid doing this is to set more general timeframes and only commit to an actual date on the calendar when I have a high confidence that my team will be able to make that date. For example, I will say that an activity like this typically will take 2-3 weeks. That way, there is no actual date given that can be written down. Then even if the date extends past the deadline, there was never a firm commitment that it would be completed at a certain time. This gives the project manager the ability to still provide a customer with status updates but not over commit to actual deadlines.
I was on the other side of this once and the company that I was working with needed to get my team information. On multiple occasions, they gave specific dates like, “we will have this information to you by Friday”. When they did this, I put a calendar reminder in for the day they gave me. When the information was not provided, I asked the very same day and they gave a new exact date. Again, I put a reminder on the day and this date was also missed. After several iterations of this, my project team lost most of our confidence in that company to be able to deliver according to its promises.
The lesson I learned from this situation and others like it is that it is better to provide schedules as more general timelines based on historical norms than it is to give an exact date. For if an exact date is missed, it reflects much more poorly on the competency of the project team.
#4 – The Customer is Always Right
Ever since 1909 when Harry Gordon Selfridge, the founder of Selfridge’s department store in London, started using the phrase “the customer is always right”, it has become a popular motto of business to convince customers that they will receive excellent service. While it is important for services organizations to treat their customers with respect and try to delight them, I feel that it has become an excuse for project managers to allow the customers to dictate how their projects should be run.
Let me give you an example from a recent project that I was a part of. There was a customer who needed some additional assistance using the software they had purchased. They convinced my boss that the reason they needed help was because their initial training was not good enough and the software was not in tune with their business needs. My boss agreed and allowed the team to go to the customer’s site for a couple of days – for no charge.
After this had happened once, the customer had it in their mind that they were the ones running the show and asked several more times for onsite help at either no charge or a deeply discounted rate. Since the precedent had been set, it was difficult to tell them no and they took full advantage of the control they had to get what they wanted from my organization.
Looking back, I realize that in that situation, my team and I had surrendered control of the project in the name of pleasing the customer. Then once they realized they had the upper hand, they were the ones managing the project instead of myself.
A couple of years later, this same customer needed us to implement different software. By this time, we had a better process in place and were doing a better job managing the customers. Shortly after the project started, they tried again to assert themselves and get my company to give them free service time. However this time, instead of giving up control in the project, we pushed back on them and said they had signed off on each of the milestone exit criteria so additional time would come with a cost. They wound up backing off and my company did not lose money on this project like with the one earlier.
This experience taught me that successful project managers need to be able to provide exceptional customer service without relinquishing control of their projects. They need to not only manage the project plan and issue lists, but also the people.
The best way I have found to do this is to start with a very detailed project plan that outlines everything that has to be done along with timelines in which to get those tasks completed. The work that the customer needs to complete needs to be clearly expressed to them with an expected completion date. By doing this, the project manager is dictating what comes next and how long it needs to take to get done. They are the ones in control of the process.
If a customer tries working ahead because they feel they know better, the project manager can tell them that they have not completed the prerequisites to move to that task and the project team will not work with them until they have the prior tasks completed. Or if the customer does not get their work done on time, the project manager lets them know that the timeline and budget are getting extended out due to their inability to meet the project milestones. This ensures that the project manager and not the customer will be running the project.
I believe there are project coordinators and project managers. Most people in the profession are project coordinators – they can make sure items are being checked off the list – but they really are not in control of their projects. True project managers are individuals that can manage a list but more importantly, can manage people. They can put themselves in their customers’ shoes and serve them well without allowing them to dictate how the project will be run.
To conclude, project managers are essential to moving their objectives to a positive outcome. Each project is different and requires a unique approach to make it successful. I would encourage all project managers to not be so rigid in their thinking. They should learn different techniques and philosophies to build their own knowledge toolkit so that they can determine which principles should be used depending on the type of project they are managing. This ability to adapt will set them up to guide their projects to positive conclusion for all the stakeholders.
Many project managers are trying to force rules from a textbook into every project that they manage. They are using certain techniques that are generally acceptable for many projects but should not apply to the ones they are managing – hampering their ability to successfully bring the project to a conclusion.
This article reviews four common project management strategies and illustrates why those strategies should not always be used depending on the type of project that is being managed. The goal is to challenge project managers to look at each project differently and apply a unique approach to all of them.