Why We Don’t Really Need All Those Experts
That training is given by people who have never been involved in the Kanban community and who may be offering substandard guidance. There is a need for quality standards so that people who pay for Kanban training know they will walk away with useful information they can apply in their organization. Software Development Times, Kanban Development, May 2012.
I love Kanban. I also fell in love with scrum some years ago. Their appeal is that they emphasize many of the good things that have worked well for me over the years. It helps when working with an organization to be able to say “give scrum a try” or “you may want to consider trying Kanban” because I know that when they dig into them, they’ll be exposed to many good ideas and approaches.
However, I’m not an expert in either scrum or Kanban. I’ve not written a book nor have I taught a class. I’ve not specifically implemented any of these technologies nor have I managed a group or project that directly used these approaches. Obviously then, I can’t talk about any of them because I don’t have any expertise or experience.
Actually, that is true for just about every successful project I’ve ever delivered and every successful organization that I’ve ever led. I was not an expert in that domain, industry, technique, methodology, technology, etc., until after we were done. Done and successful. Done and successful far beyond what those organizations had achieved in the past (at least the recent past, but often in the collective memory of the organization).
To put it bluntly, being an expert can be highly overrated
To put it bluntly then, being an “expert” can be highly overrated. I can’t count the number of “experts” who pitched or implemented “improvements” in our organizations whose only apparent expertise was getting the company to pay them money over months and years. Measurable results were pretty much non-existent.
In one organization we were paying a well known consulting firm $1 million a year to help us improve our software development, maintenance and acquisition projects. The core strategy was to move our very large and diverse organization up to using best practices and methodologies throughout these development processes. This contract had been in place for some years before I joined the organization.
About every six months we went through a new reorganization and revitalization of our efforts to improve. The consulting firm kept telling us what we were doing wrong, what we needed to do to improve and providing us training. We formed committees, called meetings, wrote new procedures and policies, set goals, created implementation plans, gave powerpoint presentations, and watched as nothing really changed over the years (except terminology it seemed — we could sure talk the talk). We kept doing what the experts assured us had worked in their other engagements, but it didn’t seem to do anything for us. We finally disbanded our special project office that drove this effort for years but we kept the $1 million a year contract because we were still determined to improve, and they were the experts we obviously didn’t have.
From the break-up of the project office, I formed a small team of four whose stated purpose was to help development teams to implement selected new technologies (e.g., metrics, new development tools, research, estimating, etc.). We had a grab bag of “things we need to do” that had been given to us because they didn’t seem to fit anywhere else (or no one else wanted them). One thing we were not given was the original core improvement goal of moving all development up to the next level of management and development best practices (in this case, based upon the SEI CMM).
To make a long story short, based upon the inspiration to provide a service rather than “implement a project,” the organization achieved its certification at operating at the next level of management maturity (i.e., the next SEI CMM level) in about 18 months. This was after years of trying, with a much larger team, and that $1 million a year consulting contract. Oh, and those $1 million a year consultants cheered us on at the end and thanked us for allowing them to finally achieve their contractual obligation. No, they were not involved in the effort nor even aware it was happening until it was clearly showing results.
For more see Don’t Project Manage Change — Provide A Service!
We became experts by taking on the effort
The lesson here was that our team had not been experts in the methodology when we kicked off this effort. We had never done it before nor had anyone ever worked in an organization or team that had used this methodology. However, everything we were doing made sense because we took the time to understand it and how what we were doing was simply a combination of good practices we had known and used in other places. Most of the theory behind the “new” methodology was for example the same stuff most of us learned in college years before (Deming, Juran, organization behavioral, statistics, Hawthorne effect, software engineering, etc.). We became experts by taking on the effort.
Experts, journals, blogs, books, seminars, etc., are all great sources of information and good ideas. However, the notion that we must be an expert before we can do something or we need an expert to tell us how to do something before we do it is, in my experience, rarely the case. Most of the real experts I’ve known are self made. They studied, researched, observed and tried things out, and became experts in the process. Few, if any, became experts by just taking training courses from experts or amassing certifications. Becoming the experts we needed is a project management tool that worked.
Are you allowing the notion of lacking expertise to hold back your project from achieving better results?
30 thoughts on “Why We Don’t Really Need All Those Experts”
Comments are closed.
Comments from around the web:
Projects being different is a separate issue from taking shortcuts. The history of project management is rife with people who constantly push for faster results by leaving out crucial tasks. Good PMs and their superiors learn that this push for shortcuts is what usually leads to project failures. That’s what PMs are there for, to assure project success, not adherence to some methodology or another.
Back to the original issue, different projects require PMs with different personalities and skill sets. Although all are expected to address the fundamentals, these varying PMs can deal with a variety of people issues.
Posted by Paul Tiffany
More comments from around the web:
Scott Hanchett • I agree very much with what Paul is saying, in my experience of consultancy no two projects are ever the same and the key is to have PM staff that are adaptable to different personalities, cultural challenges and specific project situational constraints. The basics of project management should remain the same, it’s having the skills and experience within your personality to adapt your style that is the key.
Bruce Benson • “No two projects are ever the same” … as absolutely right as this is, this notion is often a source of problems. Once we get an organization turned around and delivering projects on time (good to great quality, on budget) I too often see changes that undermine the fundamentals for success based upon the notion “but this project is different from the last one!”
I try to highlight that any project organization consists of people + processes + tools and these have as much to do with how we deliver projects as does the traditional “requirements.” When we ignore these dynamics (e.g., pick a schedule 20% faster than we’ve ever achieved in the past) with the reason “this one is different” I’ve only seen failures throughout my career.
The insight is that yes they are all different in the details, but the fundamentals are often pretty unchanging (in both a good and bad way) and it is these fundamentals (staff, organization, tools, culture) that often drive the project (schedule, cost, quality) and not as much the details (e.g., requirements). I know that sounds a bit counter intuitive, but see these two articles for examples and background:
http://pmtoolsthatwork.com/is-your-project-schedule-really-driven-by-your-requirements/
http://pmtoolsthatwork.com/software-development-repeatable-process/
More comments from around the web:
Chan Davis • Maybe my definition of ‘expert’ is different than most. I do not think you can be an expert in the IT profession, whether a technologist, project manager, developer, etc. Experience always brings you closer to the asymptote, expert. Oh, the value of experience, the more you learn the more you realize you don’t know. Certainly certifications do not make one an expert.
Sean Curley • After 25 years as a project manager I think the term “expert” is generally over-used and over-emphasised.
I can live with the term specialist – but how do we define the term expert.
Probably “nearly an expert” would be a better and more realistic description but of course that would not be marketable.
Bruce Benson • Chan, Sean, great comments and I agree. Expert or specialist just means to me that they know more than we currently know in a specific area — and that is usually what we need at the time. Some notion of “absolute expert” that knows everything possible in a broad field — just doesn’t seem probable in this day and age.
I recall years ago where people expected me to know everything about any program running on a computer, because I was an “expert on computers” (I was a programmer). I would see the look of “enlightenment” in their eyes when I would suggest they talk to an accountant about challenges with their accounting software and a photographer about a good photo editing program to buy. Of course, these experts also needed to be familiar with the same software, but I found, not surprisingly, that they smartest folks on the software were “experts” (highly experienced) in their field first and then users of software that was used in their field.
Jim Smith • Don’t you think the term “expert” is just a euphemism for a “highly experienced” individual. The label is a distraction.
I have killed or recovered over $500 million in IT projects during my consulting career, 90% were the result of inexperienced project managers being given an assignment they were woefully unprepared to execute. Most were quite capable employees, but nonetheless unqualified. That’s a leadership failure. If want want Joe to manage the project and he’s not experienced, get him some help from a “highly experienced individual ” (aka- expert) .
Peter Mehit • You’re right. Experts are self-made. If having insights from experience could be taught out of a book, everyone would be an expert. I think this is semantics. You will always need someone who has more experience or practical exposure than you to be successful. How you label that is up to you. I will acknowledge that there are a lot of fake experts, subject matter specialists and the like out there, but if you choose them without due diligence, that’s on you.
Sean Curley • Semantics perhaps is one description – but in the many projects that I have to direct or manage of course I need specialists in many various fields. I write the assignment description, skills, experience required and when my specialist arrives I will bow to his/her better knowledge and experience of the subject involved.
Interestingly if you research certain “expert” databases you can also find not just the expert professional fields but also grades of expert. For instance the European Commission – Europaid you have local exper/inetrantional expert or junior expert/middle expert/senior expert….. which I find quite farcical. What is a junior expert?
It appears to me that the term expert is often use to determine pay level rather than a description of the specialist required to the the job.
Bruce Benson • Jim,
I cringed at your comment about 90% of the PMs being inexperienced and that was the reason for failure. I do agree with the notion of a failure of leadership.
In just about all my “fixes” to projects and organizations, I had to get those leaders to quit demanding that their PMs do silly and unrealistic efforts (e.g., deliver in 6 months when we’ve never before delivered in under 9 months, and we’ve always promised to deliver in 6 months). When we based product/project delivery on past performance (we delivered the last 3 in around 18 months but promised everything from 12 to 15 months. This time, let’s offer … 18 months), those “inexperienced” PMs “suddenly” delivered on time, on or under budget and *always* with significantly improved quality. The customer always said some variation of “well, it is about time you started to deliver when promised.”
Pushing back on senior leadership is always risky, but many of them are more than willing to risk an alternative approach (along with adding “you better be right Bruce …”). It is amazing how many “bad” organizations/teams suddenly perform well and start to continually improve, when we eliminate well meaning but misguided “direction” from more senior management (who … wait for it … are actually the inexperienced ones).
More comments from around the web:
Steward Copper • You are so right but the truth is that our bosses (project sponsors, customers and so on) need to have something to prove one’s level of qualification in project management. They can’t measure our experience and “lessons learned” but they understand certificates and trainings.
So, to their money we need to play their game – attend trainings, get certifications, write PM articles and research works and so on. It’s nothing but a vicious circle.
Jennifer Bonck, PMP • My favorite is when management brings in external experts to verify that the internal resources got it right. Why hire people if you trust them so little you need someone to rubber stamp their work?
Maja Kowalski • So true! I also get very annoyed when people insist that to deliver a project with an IT component you must have 10+ years experience in IT projects. It’s a complete pigeon-holing, a “brain blinker” that in fact often results in putting a wrong person in the role.
Yaaser El Batal • Great points. I’ve always been “lucky” to find experts hidden in GPM
Frank Vettese III • Could not agree more, Jennifer. Project Management is about building trust. Experience is nothing more than a shining light through the dark tunnel of uncertainty.
Paul Tiffany • Jennifer:
If that’s true, the nexrt question to answer in a non-rhetorical fashion is why the management doesn’t trust their staff. Is it their own ignorance or even incompetence, or something else?
John Dee • Yes, Jennifer you are so right … Also don’t forget you are handed the project and expected to deliver but your employer keeps sticking his head in and screwing things up just when you got the team turned on ….
Paul Tiffany • Yeah, those stupid employers don’t know what they’re doing and always bugging their employees to determine what they’re doing. Heaven forbid they might be doing something directed by the executives.
Terry Cohen • This stream of responses sounds more like whining than adding value.
I don’t believe certification in and of itself makes a person better in a role. I have worked with and interviewed a good deal of people with certifications that I don’t believe are very good a project management. I’ve also worked with excellent PMs who have no certifications. I strongly believe experience is more important than certifications. As I’ve mentioned in other streams, project management is a combination of science and art. The science can be mostly taught in classrooms and through certifications, but no PM certification will teach the art of project management (e.g handling company politics, managing a difficult stakeholder, having alternatives when an issue arises). Good skills in the art of project management comes from experience.
However, when hiring a PM, the initial screening of the candidates is typically handled by a HR representative. It is unrealistic to expect HR to be knowledgeable on all areas of skill required within the company and to be able to determine from the content of a resume if the applicant is a strong candidate. Rightly or wrongly, the certifications are used as an easy way to perform initial screening. I don’t agree with the practice because I believe a company misses out on a lot of good candidates.
Yaaser El Batal • Terry ,I’m agreeing with your points ,but this art gain gain through certificates if you had the talent and looking for the experience it will help , listening to the writer is better than read to him a 100 book.
Timothy Noxsinz • Paul to respond to your question, I think politics and control are a big part of organizations… that is why management gets involved. I doubt if ‘trust’ is bankable in such contexts. I guess PMs have just to brace up to such realities.
Paul Tiffany • I’m with you Terry.
The single most important question that I’ve never heard asked in an interview of PMs by others (or during review of résumés) is: What is your project success rate?
I’m often fascinated with the responses I get to that question even before raising the issue of the definition of success.
Last year, I was talking to the head of the PMO at a financial institution who said he was mimicking the organization and processes that I instituted at another financial institution and they were having extraordinary success. Well into the conversation, he let drop that less than fifty percent of their projects were succeeding. Oops! Now, I knew why he was talking to me.
Terry Cohen • Yaaser, in project management talent comes from experience. You can listen to seminars and read books but that won’t replace experience. Project management is a very dynamic environment, and a PM walks into many different surprises and must be able to deal with each situation. The ability to react and think on your feet is not taught in a classroom. However, I’m not saying don’t go to courses, seminars, and workshops. Getting back to my previous point, a solid PM is well rounded in both science and art.
Maja Kowalski • Terry, not sure about your point that “talent comes from experience”. I have worked with people who call themselves “project management veterans” with 10, 15, 20+ years of experience and I wouldn’t call them talented. They follow a structure, have been managing similar projects in a repetitive manner and yes I’m sure they’ve become good at what they do but I wouldn’t say they’re talented. On the other hand, I’ve had a few junior PMs or Project Co-Ordinators aspiring to become PMs, who I would definitely call talented, and have the right attitude.. something that is often missing in those with years of experience, certification and all the other widgets that supposedly make them great PMs.
Terry Cohen • Maja, I agree with your point that not all experienced people are talented. Experience doesn’t guarantee the development of talent. Think about how many bad drivers are on the roads that have been driving for many years. However, a PM in a highly political and confrontational environment stands a better chance of being successful if they have experience dealing with similar environments. The success in this situation has less to do with a solid plan and a comprehensive set of issue and risk registers, than it does on their ability to build relationships, manage stakeholders and their expectations. There are definitely extremely talented young PMs who can succeed in those environments, but would you consider them to be the norm? I wouldn’t. Attitude is a completely different category. A less than desirable attitude can exist for many reasons including, boredom, events in their personal life, feeling they’ve been set up to fail, or just plain arrogance. A bad attitude can exist in anyone, whether they have many years of experience and/or certifications, and it will always tip the scale towards failure.
Paul Tiffany • I think you fell into a semantic trap. I believe that Terry’s point is that progress from Junior PM to PM and PM to Senior PM generally comes from developing the people and political skills that aren’t expressed in any methodology or process.
It’s also okay for a PM to do an okay job. It’s a tough job. It would be great if all of our PMs were exceptionally talented. In assigning PMs to various projects, I take into account a number of factors. Some projects need a nose-to-the-grindstone person, another a militaristic by-the-book, another a creative/flexible, another a collaborative, another with special SME knowledege and a few that are exceptionally talented, often risk-takers, sometimes charismatic and sometimes not so well liked but results-oriented. Which will most likely be successful?
Bruce Benson • Great feedback and comments everyone. I would only add that except for some “organizational behavior” classes in college, I saw very little training being given in people/political/organizational change skills in project management training courses (certification granting, etc). I spent a year at the Software Engineering Institute where the most valuable things I took away had little to do with software or engineering. Instead it was the deep dive into change management and technology transition (how individuals organizations adopt/resist new things). The best books I’ve found on organizational politics were books written for … consultants (e.g., “Flawless Consulting” – the book is better than the title).
Of course, training/classes/certifications are not the same as getting the experience and actually learning/growing from that experience. However, as experience and training tells us, we often have to “play the game” and get the pieces of paper, if we want to stay in the game. When the bosses bring in outsiders to “help” or “verify” what we are doing, it is part of the game and we should find ways to leverage these kind of situations (I’ve convinced a few outside consultants to advocate my position back to more senior management for example).
Great discussion.
More comments from around the web:
Dr. Gaby Cora, MD, MBA, http://www.DrGabyCora.com • You gave the solutions away before they hired you, Bruce? This happens way too often. I’ve learned the hard way. Now I shut up, realize what’s going on, write my proposal, send it for approval (and payment) and once it’s accepted, I move fast, assess in depth and find the solutions with the right strategic execution. The biggest problem I find for consultants is we make it sound so easy “anyone could do it!”
David Smith • My advice would be to exercise the utmost of caution when adopting the following philosophy:
“We don’t need experts in a process; what we need is process management experts.”
I’ve witnessed situations where the “process management experts” don’t seek to understand the process and as a result recommend changes that result in suboptimization.
Bruce Benson • Gaby,
I’m often guilty of giving away the solution. I’m just always amazed how many people don’t just grab it and run (because I do make it sound fairly easy — and it is … but ….). Some folks recognize that even given a solution there needs to be leadership to make it happen (and help make the tactical decisions based upon the chosen strategy). Other folks just “don’t get it” and with them I assess the effort to bring them up to speed while executing the strategy. More often, if I get the blank stare (and I’ve not just mis-communicated) I’ll walk away as the effort is now much bigger and I shy away from trying to fix too many things at once.
Bruce Benson • David,
Huge topic of discussion: “We don’t need experts in a process; what we need is process management experts.”
I’ve seen similar too often: “Gee, we have a quality team, so let’s put them in charge of the project and that will solve the quality problems!” “Our projects are always underestimated, so let’s get an expert in Monte Carlo simulation to do our project estimates!” None of these worked, of course. But it is amazing how many people can be mesmerized by the notion of an “expert” and by a methodology that sounds sophisticated and complex and … not understood by the folks edicting its use. We didn’t see suboptimzation, just the same old late and buggy project deliveries.
Great subject.
More comments from around the web:
Some of the PM training I took at CSC on Skillport was about the importance of planning all aspects of communication for the duration of a project. This was mirrored in other phases of PM as outlined in The Guide.
Posted by James Ascher
More comments from around the web:
Chan Davis • Maybe my definition of ‘expert’ is different than most. I do not think you can be an expert in the IT profession, whether a technologist, project manager, developer, etc. Experience always brings you closer to the asymptote, expert. Oh, the value of experience, the more you learn the more you realize you don’t know. Certainly certifications do not make one an expert.
Sean Curley • After 25 years as a project manager I think the term “expert” is generally over-used and over-emphasised.
I can live with the term specialist – but how do we define the term expert.
Probably “nearly an expert” would be a better and more realistic description but of course that would not be marketable.
Bruce Benson • Chan, Sean, great comments and I agree. Expert or specialist just means to me that they know more than we currently know in a specific area — and that is usually what we need at the time. Some notion of “absolute expert” that knows everything possible in a broad field — just doesn’t seem probable in this day and age.
I recall years ago where people expected me to know everything about any program running on a computer, because I was an “expert on computers” (I was a programmer). I would see the look of “enlightenment” in their eyes when I would suggest they talk to an accountant about challenges with their accounting software and a photographer about a good photo editing program to buy. Of course, these experts also needed to be familiar with the same software, but I found, not surprisingly, that they smartest folks on the software were “experts” (highly experienced) in their field first and then users of software that was used in their field.
More comments from around the web:
Neil Habrial • Bruce, that is the problem. In the many companies I have been associated with or worked for, there are the type who believe that waiting for a proper security evaluation of an IT environment too much to ask for, and move forward. Then try to blame the security team when it is hacked. Exactly what you are saying is the problem. Getting expert input for many things are not only a good idea, but may save your project. I agree that one can take needing experts too far and not all experts are really experts, but in this complicated world, chucking the experts and “going for it” has costs lives and at minimum, gains much embarrassment.
Dr. Gaby Cora, MD, MBA, http://www.DrGabyCora.com • Experts can be of great help but nothing beats common sense. If you are in a position where you can’t successfully resolve a problem, bringing someone with known expertise and experience can help you solve the problem fast efficiently and with little pain. I’ve come in to help out across industries and I’m often hired when people don’t know what to do, they are in a crisis or both. Experts need to be hands on and committed becoming a part of the team. Pointing in the right direction from a distance doesn’t work.
Neil Habrial • That is confusing expert with consultant. The vast majority of the experts are in the company, hired employees, totally wanting to make the company successful. These people are not only expert in their field, but the company it self. Bringing in an outside consultant is a much different situation. The question was about experts. I have no desire to put down common sense, but going back to that molasses tank in Boston, the person did not bring in an expert and thought common sense would work. A gigantic mess and several dead later we know the truth. Yes, that tank held much molasses for a while, but in the end it was a disaster. In the IT security world, everything happens faster. Putting aside the law GLBA etc…, most do not know what a hacker can do with a given situation. You were able to get the data there, but everybody has a copy now. You got the specific need done, but the consequences can take down the company. As I stated before, this can be taken too far and for the wrong reason, so I am not going to deny that there are times when you don’t want to waste the time and money.
Another point is that you are talking that you will only need an expert to move your project forward. Many of the necessary experts are more covering your flank than actually putting a tangible thing into place. That flank can be the law, preventing ripoff, and making something safer. The initial comment acted that that is not necessary. In this world where hackers and lawyers are all looking for more work/fun, it is very necessary.
Dr. Gaby Cora, MD, MBA, http://www.DrGabyCora.com • I’m an expert consultant and there are many expert consultants. I would never hire a general consultant who can’t focus on the real issue and help resolve it (as an expert, of course!) We come in and out: we serve the purpose of being an objective collaborator who is not focused on the problem (which is why it may not have been resolved yet) but on alternative solutions to resolve the problem. We expedite the resolution, help create and execute a plan of action, see that it’s on its right course and we leave. I’ve done this tons of times, working with people at the top, with groups, with companies and more. And, in addition to expertise, we need common sense as well as combination of leadership and mediation qualities. Some companies hired me even though they knew how to resolve the problem because they needed a back-up for legal reasons. However, they have always said I added value to what they initially had in mind.
Brian Hathaway, MBA, SSBB • After reading the article, the issue to me was that there was a top down improvement effort going on that didn’t get buy in from the people closest to the process. The fact that the company went through several reorganizations raised a red flag to me. Upper level management needs to set strategic direction and stick with it. This company sounded like a golfer who was unable to find his center, continually making adjustments with no positive result. I suggest that a better approach is to set performance goals that are specific, measurable, time-bound and achievable. The organization must then be energized by building a critical mass of experts who understand how to use accepted improvement methods to improve processes and deliver results. Outside experts do have a role, but sometimes there are other solutions as well.
Bruce Benson • Neil, I agree, there is a balancing act that we need to do. My experience is primarily with organizations that are struggling, have been struggling for years, and have generally attempted to fix the problems by going to outsiders, instead of using the resources (i.e., people) they had. When we broke these patterns and “fixed” these organizations it was never from “finally bringing in the right consultant/expert” but from drawing on the needed actions and expertise from the folks already there. At least in the technology intensive organizations I’ve worked in, we rarely had “technical” problems we could not solve (no Molasses like disasters). Instead the challenges were managerial and that often included people who just “knew” what needed to be done (like the Molasses example I suspect) and when we cleaned up the problem (e.g., failed project) it was always with in house experts that were previously ignored/overruled. I’m not saying that outside experts can’t be useful (your and Gaby’s comments) but that we, in my experience, too often overlook what we already have in our own backyard.
Bruce Benson • Gaby, thanks for sharing your experiences. Humorously, I once had a job interview with a well know 4 letter consulting firm. During the round of interviews I found myself helping them to plan for a huge federal contract they had just won. It was clear they didn’t have a strategy or the expertise (yet) to tackle the job. While the troops who would do the job were clearly not yet up to the task, I found the partner who ran this outpost of the firm to be brilliant. I had no doubt he would figure out how to do it (it didn’t include me, he was too stingy ;-)). Effective consulting is hard and not everyone can do it well. When we find that great outside consultant/expert it is like striking oil — too rare for the number of tries, but amazing when it happens.
More comments from around the web:
Alan Chenkin • The real danger here is that many experienced people with great skills get ignored because the hiring authority really does not understand what is needed, or believes that Certifications have more value than knowledge gained in the field. I have many certifications in dead products and am too busy to get the multi-year certifications that the requirements writers demand (It would take 10 years to get all the certifications in the products I work with – a Phd is easier to acquire); Yet I save major organizations millions in recouped costs and efficiencies (ROI). While we have to avoid charlatans (think ex-yahoo ceo, and others who fabricate credentials) – Experience, past projects, employment, and successes will demonstrate the capable and worthy individuals who make projects winning propositions. Smart Project Managers know this, and their interviewing skills reflect it.
My team is a hand-picked cadre of serious and dedicated professionals, with lots of exposure to Agile, PMBOK, Six Sigma, kanban, and application knowledge. There is plenty of alphabet soup after our names, but the results make the difference.
Bruce Benson • Alan,
Great points. I’ve always been “lucky” to find experts hidden in my teams or nearby teams. It just takes the time and effort to find and/or develop them.
I watched as one organization implemented PMP and Six Sigma Black belt programs. The only real difference I noticed in the PMP training is the number of people who now put “PMP” in their signature lines. Otherwise, everything stayed the same. For Black Belt, I would see an ever increasing list of “who achieved their black belt” (and got a bonus for it) but no increase in the use of data or understanding of data in planning and tracking projects or in improving existing processes.
Don’t get me wrong, I think these are both potentially great programs (I’ve completed similar programs years ago and use the techniques daily), but too often we get lazy and look for the pieces of paper, rather than dig deep to find out who would really bring what to the team (and really know what we need). I wrote a short article on the value of such certifications: http://pmtoolsthatwork.com/dont-get-everyone-project-management-certified/
Thanks for the comment.
More comments from around the web:
Bill Ross • Bruce .. the thing is we learned this a long time ago. We were sent to do a job no matter what our background at times and we got it done. Industry has forgot how to do this and mucks things up with “experts”.
Jeffrey Brehm • Agreed, Bill … Industry … and many of our so-called “leadership” (and hiring managers) have forgotten just what _any_ successful military person can bring to their bottom line.
…
Good find, Bruce!
Bruce Benson • Bill, Jeffrey agreed. That was one of the great things about the Air Force, we had a job to do and it needed to get done with whatever resources we had. It made for a lot of hard work and a lot of creativity and we learned how to solve problems when we were not always the experts.
Neil Habrial • Very amusing. Ever hear about the great Boston molasses flood? A non expert build a million gal tank to hold molasses and it broke killing several people. Yes, you don’t need any experts. I work in it security protecting your credit cards. I guess you don’t need me either.
Bruce Benson • Neil, the notion is that we in large part grow our own experts, as needed. The other part of the notion is not to get “stuck” because we don’t think we have the experts we need. Most of us were not experts, until we dug in and became one — often out of necessity, and not necessarily through planned education and training. Experts and expertise are wonderful to have, and there are multiple ways to fill the need.
Comments from around the web:
Kevin Hoffman • I think that it is much easier and more powerful to coach subject matter experts to use efficient project tools and approaches, than to try to somehow train “project experts” to know enough about the processes to not be dangerous. I think that the “Project Management Office” approach is loaded with inefficiencies: additional communication layers, alternative agendas, and mistakes in process understanding.
Bruce Benson • Kevin, Agreed.
I’ve never seen a project management office approach that worked. In just about all cases, a PMO (or project management in general) was implemented as a patch on a dysfunctional organization. The departments/teams did not work well together and someone concluded that they needed to improve their project management. I’ve seen similar with six sigma, quality, development methodologies (IE, OO, CMM, agile, scrum, etc.). They were all effectively unsuccessful.
In those case where we were successful, the folks doing the primary job (development, IT, engineering, etc.) took up the effort themselves to learn what needed to be done and just did it. They adapted it based upon their local conditions and were very successful – it became just they way they worked, and not a bolted on initiative that wasted time to “comply” with.
Anytime we had a significant third party involved (process improvement office, PMO, six sigma office, SEPG, etc.) it was never very successful, just a null activity (at least relative to what we finally achieved, there is always some good that occurs in any activity).
For the “coaches” we concluded that a service oriented approach worked well rather than the typical top-down-directed effort (see: http://pmtoolsthatwork.com/dont-manage-change-provide-a-service/ for how we did it in one case).
Good comment.