Precision With a Wide, Moving Target
One of the requests that I don’t think will ever go away in training and mentoring is the request for a recipe. Many people in this YouTube world of short attention spans aren’t interested in taking the time to understand topics in depth, they just want to know what will work, and simply apply it. Sorry, but I don’t think that makes for things more complex than chocolate brownies or IKEA furniture.
The request is understandable, given how we are raised. Schools, even through many undergrad courses, are primarily based on rote learning, where the teacher tells you something, you memorize it long enough to regurgitate it on the exam, and you proceed to the next level. In the industry, many certifications are awarded via computer-based multiple guess tests, where the greatest challenge is to memorize a massive body of knowledge, and parse those questions successfully at the testing facility.
Even if there is a requirement for industry experience or ongoing learning, proof is rarely audited, and only proves attendance, not effectiveness or even absorption. We pass the test, we do our time, we are rewarded. Plenty of people make plenty of money perpetuating this style.
I’ve noted publicly before that certifications are, to my mind, an indication that the successful candidate has demonstrated an ability to pass the exam, not to be effective in the workplace. Certifications are learner’s permits.
When it comes to effectively running projects, or analyzing or architecting complex systems, or indeed any problem where there is inherent complexity in the domain or the resources you need to wrangle, we are in a different world. Recipes and rote learning no longer apply. Sooner or later (usually sooner), the person that has leaned on rote learning will run into a situation that hasn’t been covered in that wealth of knowledge that has been absorbed. There is no rote answer.
Let’s look at project management as an example. This is a field that certainly predates technology (can you say pyramids here?), so good practices in this area have been around (and been tested) for quite some time. Even with decades, arguably centuries of background, this discipline still will not yield a recipe for success. Two reasons:
- the body of knowledge, that golden standard against which certification is based, remains a moving target, and
- this knowledge needs to be applied to such a wide range of instances that no one approach could ever solve all these problems.
The PMBOK Guide is now in its 4th edition. Each time, every few years, people take on the task of updating the previous addition to increase clarity, and revise or expand the information therein. In early revisions, it was not unheard of to see essentially a rewrite of whole chapters. After every release, anyone that trains against this guide scrambles to understand the differences and update their materials accordingly. It is safe to say that previous contributors are at times not all that impressed that someone has stepped on their toes.
There is no reason to believe this practice will ever stop, if only for the reason that there is a perception that information that is more than a few years old has to be out of date. New revisions will come and go, and projects will continue to succeed and fail, being run by people that have been certified against this body of knowledge.
The model works for the vendors, though, so there is no apparent need to change it.
The real problem is the assumption that a recipe can be applied to such a wide range of problems. As projects have such a wide variation in size, breadth, domain, criticality, urgency (and who knows how many other factors), recognizing that we need to grow our knowledge in a different way.
To deal with all the variations that could hit us on projects (or any other complex problem, for that matter) we have to step back and look at the issues as general principles, and our projects as systems.
We will need to understand scope on every project, but how we do so depends on the project. Same with every other step along the way. If we learn one way, we are constrained to a very narrow range of projects where our recipe works.
We will need to recognize that our projects include all the stakeholders on the project, the business environment in which the product resides, and many other external influencers. This systems perspective forces us to recognize the human element, something that has been given very little focus on existing bodies of knowledge.
Recipes will always be sold, and have their place in the early stages of learning a discipline. They will never form the basis of true excellence in any complex discipline. – JB