March 28, 2012 at 5:40 pm #157417
This was spurred by a student’s comment in my project management communication class that everything I have been talking about is common sense.
“Exactly!” I said. “Now, would you also agree that losing weight is just a matter of eating less and exercising more?”
“Yes, ” she said.
“Then, why do we have so many diet commercials on TV, diet books in the bookstore, and we still have an obesity epidemic?” I asked.
Maybe project management isn’t common sense? Discuss.
March 28, 2012 at 5:54 pm #157462
I’m not a project manager, at least not now, but I’d bet that in theory that student is on to something. However when applied, Murphy’s Law takes effect, and that’s where the real project management skill comes in. Plus, remembering steps to the process is important, even if the process seems like common sense.
March 28, 2012 at 6:11 pm #157460
Common knowledge? Sure. Common practice? Not so much….
March 28, 2012 at 7:54 pm #157458
I’m also going to blame DOD-STD-2167 in the 80’s standardizing on waterfall for software projects and making a big influence on software development projects everywhere. They replaced it with MIL-STD-498 in 1994 which supports iterative development, but the damage of organizational momentum had been done.
Yes, I think the waterfall mentality is largely to blame for project failure.
March 28, 2012 at 10:23 pm #157456
There is this idea in government that you can rationalize away human emotion (especially negative emotion) by instituting processes for everything. Project management is essentially a nice way of saying “Let’s get people together and make them work on something.” When in human history has that ever been easy or common sense-driven?
Maybe we should also ask whether we do enough in government to manage feelings.
March 29, 2012 at 12:00 pm #157454
Would offer that project management is in fact common sense AND/but there is a need to teach/reinforce the skill set to implement common sense
March 29, 2012 at 3:24 pm #157452
Maybe common sense isn’t so common 😉
March 30, 2012 at 12:53 pm #157450
one word: “discipline”
March 30, 2012 at 12:55 pm #157448
Alton Lavallis MBA,PMP,PMI-ACPParticipant
I agree that a lot of what we do in managing projects comes down to common sense. Unfortunately that common sense is often not applied early enough in the game.
Raise your hand if you’ve ever been given a program/project and received additional assistance by being told: This is how much it will cost, and this is when it will be finished.
Involving the PM in initial estimating and budgeting reduces the number of failed projects.
March 30, 2012 at 1:54 pm #157446
I promise, I’m going to go somewhere with this, but I don’t neccessarily agree with the statement “losing weight is just a matter of eating less and exercising more”. There is a growing body of evidence that not all calories are processed the same in our bodies, and that once weight is gained and kept on for a certain period of time, its almost impossible to keep it off. Add that complexity to individual variation, and all of a sudden this problem with a common sense solution isn’t so neat and tidy, and is actually pretty complex.
The same goes for project management. On the surface, it seems like common sense. Communicate with your stakeholders, stay in scope, etc etc etc. But we all know its not so simple. Project management is a complex discipline that is about 10% technical skill (budgeting, tracking, etc) and 90% people skills (and I think I’m being generous with the amount of technical skill involved). And like Danielle said, getting people together and making them work towards a common goal has never been common sense driven. Nothing about human emotion and interaction is common sense.
There is a danger in oversimplifying project management to common sense, especially when it comes to trying to encourage more disciplined project management practices across government. Why would management make a commitment to something as “common sense” as project management? Especially in a science heavy (read: full of scientists & engineers) organization. They are all so smart, if its common sense, they are probably already doing it. (Then there is the sentiment that PM is just meaningless bureaucracy that gets in the way of actually getting projects done. Projects that fail 70% of the time. But that’s another topic altogether)
Characterizing project management as common sense is selling it short, and inviting a lack of discipline to a field that is all about discipline.
March 30, 2012 at 2:14 pm #157444
Among the “common sense” things that PMs do is assist with creating effective charters, complex WBSs, communication plans, building schedules in MS Project updated through PWA, building tasks with appropriate constraints/predecessor-successor relationships/lead-lag-slack, understanding and interpreting the critical path, understanding and articulating the consequences of various task types (fixed units, duration, work), baselining, EVM analysis (SPI/CPI/EAC/BAC/etc.) , analyzing resource levels & crashing tasks if applicable, etc. And those are just a few things that came quickly to mind!
For most of us in this profession, the mastery of these “common sense” principles and skills has taken thousands of hours of experience, hundreds of hours of education, and the obtainment of a rigorous, internationally recognized certification!
March 30, 2012 at 2:53 pm #157442
Stefany M. MercerParticipant
Well said, Tracy!
Thank you for the input! 🙂
March 30, 2012 at 3:55 pm #157439
For several years, we had a division dedicated entirely to this question. They had authority to poke and prod, interview, document and report back through the DBSMC to Congress. They looked at six areas: Operational, financial, human, strategic, legal/regulatory and technology. Some really excellent people ran the operation and several of them are still employed throughout the DoD.
What they discovered was that most projects are not failing due to lack of training, PMP’s, project staff, or dedication from PM’s. They found that projects were failing due to other factors, usually factors outside the control of the PMO and project staffs. Here is a short list of things I can remember off the top of my head:
- Lack of sustained leadership. This is not just about the PM, but about the people the PM reports to.
- Poorly documented requirements. Senior leaders often take on a monarch-like posture and declare that a solution is needed without knowing or documenting what the true requirement is.
- Changing requirements. Once a PM’s interpretation of a requirement is delivered or demoed, the “requirement” is changed. Either someone says they didn’t interpret correctly; the leader who started it moved on or fell out of favor (lost power), the customers were newly included (where they were not included before), etc.
- Laws and policies change. Projects have to be re-engineered to keep up.
- New “standards” are applied. Whereas standards were not considered or applied in the first place, and no mechanism exists to gently phase in new standards over time. Projects have to be re-engineered to keep up.
- Dependencies were not considered early on. Things like security and interoperability were left out of early discussions when the requirements were established. These items were not budgeted for. Projects have to be re-engineered to keep up.
- Lack of coordinating mechanisms across large departments / agencies. No single repository of standards exists. No publishing / feedback / updating of planned updates exists that would involve customers, users and other stakeholders early on. No mechanism for documenting and sharing what works well. No mechanism to allow for common supplier engagement (that would naturally result in cost reductions).
- Too many masters / too much oversight. A PM rarely has one person they have to report to. In fact, I’ve never seen a case where they have. They usually report to a whole mess of “masters” including multiple “leaders,” customers, and oversight bodies. These many masters rarely communicate or coordinate with one another, and they often exert opposing force on projects – leaving the PM in the middle to once again “interpret” the outcome – which will later be declared wrong by one or more of the people they report to. Projects have to be re-engineered to keep up.
- Redundant / Competing projects are surfaced. When this happens after a project has been budgeted for and work has started, turf battles and power struggles emerge. Changes can’t lawfully occur without going back through the budgeting process. No one wants to pack up and go home, so projects are “de-conflicted” by compromising on some requirements, sliding the schedules for individual requirement build-outs, and PM’s resorting to re-branding (an effort that takes more time away from PM duties). Projects have to be re-engineered to keep up.
Is it any wonder why such a high percentage of projects fail? Or that so many of our programs end up on OMB’s high risk list? See attached list. It’s from Q4, 2007, but it makes the point. How many programs have been removed from this list in the last five years? The traditional answer has unfortunately been to add more oversight or bash an already overwhelmed PM in the noggin.
From the ERAM team Web site: “An analysis of ERAM risks reveals that many program risks are external and beyond the control of the Program Manager. Mitigating external risks often requires senior executive engagement.”
March 30, 2012 at 4:09 pm #157437
Kenny Paul KeelParticipant
It can be as simple as common sense, as long as everyone does what they are supposed to, in the time that is required, and nothing unexpected arises. But how often does that happen?
March 30, 2012 at 4:27 pm #157435
I would guess, Bill, that what you are teaching in a project management communications class is true for successful communications in general, right? There is nothing special about project management communications except that a project manager has so much riding on thier ability to communicate. So, from that perspective it is “common.” But common is not the same as simple, as Tracy points out, or easy, as Brian expressed.
The person who wrote the one word response: “Discipline” may be saying that it is one thing to know in your head how to communicate to pass an exam and another to apply it. We communicate from the moment we are born and accumulate very ingrained habits along the way. Some of them are good, some, not so much. We also learn skills unknowingly from good communicators around us. So yes, a few have “natural” people skills- but they aren’t always the most disciplined in other areas neccesary for successful project management. The rest of us have to apply discipline–particularly the discipline to step outside of ourselves– and build new habits using those “common” best practices. Brian, is it correct to say that is where the “thousands of hours” comes in? Could it be that the demand for good project management exceeds the supply because these skills rarely come together as a package?
I do think that the basic principles of good project management are NOT common knowledge in the government, and that they need to be. The PMI certification (which I happen to have) is geared toward mega projects (100+ human resources). I venture to say that most of us on GovLoop are working on projects that involve relatively few people in execution, but that impact many thousands or millions of people. The government needs to find a way to inclulcate the basics with entry and refresher training…for anyone who is does project work. And that is most of us.
March 30, 2012 at 4:28 pm #157433
Sure it’s all common sense.. but you have to apply that within the context of the bigger picture to be successful with it and sometimes you may not know enough of the surrounding details to be able to do that. I’ve thought about a number of projects but then after investigating what other activities were going on decided to abandon them because they either didn’t add sufficient value to justify the cost of engaging in the project or someone else had a similar idea with better end result execution or some upcoming policy change would render my efforts useless. So not all “failed” projects are bad. And I think if the individual engaged in the failed project is able to take away valuable skills and knowledge then the failed project in some cases may not be wasteful either.
It’s the same thing with research. Just because you validated the null hypothesis does not mean your research project was a failure. Validating the null hypothesis can contribute a lot of very useful information. Same goes for projects. We really should reframe that term “failed projects”.
March 30, 2012 at 5:12 pm #157431
Admittedly, a portion of my thousands of project management hours that I documented to qualify to sit for the PMP were not necessarily spent engaging in “best practices”! But I would like to think there was continuous improvement that culminated in a stricter adherence to a PMBOK oriented doctrine of PM. I agree, Daniel, it comes from building a broad project management skillset that largely results from experience. Therefore (please forgive me for referring to myself in the 3rd person), PM Bryan version 2012 has a lot more “common sense” than PM Bryan v. 1996!
I like the diet analogy. I would also offer a comparison to driving. It is common sense: steering wheel, pedals, turn signals, traffic lights, etc. – why would anyone need to go to driver’s training? And is there a difference in skill between a newly licensed high school kid and a driver that has been licensed for 10-20 years or a driver that has had advanced driver’s courses?
March 31, 2012 at 5:29 am #157429
The main culprit I have seen is not a lack of common sense, but a failure of leadership. Combined with a lack of accountability for results, I would pin these two dependent factors as common denominators as drivers of project failure.
These two drivers hinder execution, which helps create the tactical list of issues David Dejewski mentioned. Regretfully, by no means is this list exhaustive.
March 31, 2012 at 5:59 pm #157427
Project management is common sense, but there is an assumption that the single variable as to why projects fail or succeed is due to project management. The reality is that one cannot “manage” human behavior and human response to the changes to the processes and symptoms that the new projects are attempting to change. Users and/or stakeholders are the ultimate X factor with any project because their feelings or responses to change is not about common sense. The only thing that can be done from a project management perspective is to acknowledge user/stakeholder response as a risk, and actively manage and mitigate it. That’s why organizational change management on any project is so important.
April 2, 2012 at 11:32 am #157425
Almost any non-technical profession can be labeled as “common sense” at the surface level. Finance, accounting, contracting, management, education, etc., all have a large element of common sense. I can balance my own check book and do my own taxes, so why would I ever bother to major in finance or accounting? It’s all common sense…
April 2, 2012 at 2:18 pm #157423
Wow! Thanks everyone for the great responses!
1) Project management is not common sense because even small projects can become complex rather quickly.If common sense is a making a judgement based on a simple perception of the facts, then the judgement will always be based on a incomplete understanding of the situation.
2) Watching the NCAA games has convinced me that basketball is a simple sport. I say this because I am quite proficient with my Wii and my XBOX Kinect. Thus, I should be able to play for any of the championship teams. Right?
3) Danielle: Great point about emotions! Maybe that is why there are more seminars and books for project managers on emotional intelligence.
4) David: Incredible resource! Thank you very much for the research goldmine!
5) Josh: And my engineering students would ask how you would use agile to build a road? Or use agile to retrofit a building for LEED certification. Is agile common sense?
6) Tracy: Love the nutrition example! It’s amazing how quickly the conventional wisdom changes everyday. For example, you see stories that tell you coffee is bad for you. No, wait, coffee is good for you. Well, coffee is good for you but it’s the artificial sweeteners that are bad for you. But sugar is toxic. No wonder there is the evidence-based medicine movement.
7) What kind of discipline are we talking about? Following rigorous processes? Making sure the project team reports their status accurately and frequently? Involving the project manager earlier in the process?
April 3, 2012 at 1:27 pm #157421
Project implementation is just like communication. Communication is only as good as it is received by the intended recipient. In other words, if I’m talking to someone and they don’t understand a word that I’m saying, then my attempt at communication has failed. Project management is the same way. If you are managing a project and those that were suppose to benefit from the change don’t receive it, then the project has failed.
The problem with the project management discipline, as I see it, is that the current body of knowledge doesn’t account for stakeholders at all — it only discusses things related to the project bottom line (i.e., those processes necessary to keep a project on time and within budget). As such, the current PMBOK talks about processes such as schedule management, cost management, human resource management (i.e. ,project resources), risk management, etc. There is nothing in that body of knowledge that speaks to negotiating people’s reactions to change (i.e., reducing risk of negative reaction to change), or what I call stakeholder management. In my 13-yr career, in order to get project managers to even pay attention to managing stakeholders, I’ve had to couch it as risk management (i.e., managing people related risk), and managing those risks at the project level along with all of the other project risks. I have been on more system implementations than I care to admit, and that is what has worked best for me.
No — it isn’t about more rigorous processes or status. But in order for the project management staff to see organizational change as important, I had to MAKE it into something they understood, which is risk management. At the end of the day, a project manager can have perfect processes and implement them flawlessly, if we are talking just about the processes in the existing PMBOK. At the end of the day, if the end users reject the change, then your project has failed. So if you want to reduce the risk of failure, then increasing stakeholder management is the way to go. That’s not to say that rigorous PMBOK processes aren’t important. It is to say, however, that we need to get our heads out of the sand and stop undervaluing the people aspect of the projects that we manage, and that the two aspects of project implementation (project and stakeholder management) need to work together in order for everyone (project team and stakeholders) to be successful.
April 11, 2012 at 2:52 pm #157419
You must be logged in to reply to this topic.