The Planning Paradox
| By Lynda Bourne
How much detail is too much? Traditional views tend to favour a management approach built on the assumption more detail is better, and to a point this is undoubtedly correct, insufficient detail in a plan of any type is a sure way to fail – ‘just-do-it’ at the overall project level does not help. But looking at the ‘Coastline Paradox’ and using the length of a coastline as a synonym for the duration of a project suggests there is a point where too much detail is counterproductive. The coastline paradox states that as you increase the detail by using smaller units of measure, the measured length of the coastline increases. If you use a small enough unit of measure, the length becomes infinite. For a more detailed explanation see: The Coastline Paradox Explained https://en.wikipedia.org/wiki/Coastline_paradox So, what does this mean for project controls and project management? No one navigating a ship into a UK port would be happy using a map where the smallest measurement was 50 km, significantly more detail is needed, but they do not need absolutely everything about their intended destination. What’s needed is useful information at an appropriate level of detail, the same goes for you, when navigating your car in a strange city[1]:
Finessing project plans to present useful information at the right level of detail is not easy, decisions have to be made! Take a typical risk register, if you tried listing every conceivable risk, the document would emulate the ‘coastline paradox’, and be of almost infinite length, which means the register is never finished and the project does not start. Conversely, miss one or two significant risks and the project team may have a very unpleasant experience, possibly causing the project to fail. Pragmatic guidelines about the risks to be considered are needed and these have to be tailored to the project. Similar guidelines are needed for the schedule, cost plan and all of the other sub-plans needed for a project. How much detail do you feel is appropriate for your projects? [1] Image source: Understanding Design, The challenge of informed consent. Dr. Lynda Bourne, 27th November 2014; maps of North Sydney |
Project Management: Talent or Skill?
|
When my son was a little boy, he was a great enthusiast of world-class soccer players and enjoyed questioning me: "Is a great soccer player born with talent, or did they practice harder than the others?" Being the native consultant that I am, I replied to him with another question: "What do you think?" From then on, I was amazed by his train of thought being developed through this old yet complex question. Through my many years of experience in consulting (and my licentiate degree), I got close to many people who were interested in growing their careers as project management professionals. I acknowledge a sense of pride in having collaborated in different ways with many of these stories. But, as an outside observer, every now and then I find myself asking the same well-grounded question brought up during that talk with my son: "Can a project manager achieve excellence through training and experience, or are there innate characteristics to this professional?" Perhaps I should begin this reflection by attempting to identify what makes a project manager a successful professional. As it has already been written about before by many others, and aware that the list takes many characteristics into account, I will stick to those traits that I most like to see in a professional:
We probably think that we have some (or all) of these skills. By admitting shortages, it is also natural to imagine that these skills may be developed through some specific training. I agree with that. However, I believe that we may recognize how rare (and challenging) it is to identify all of these characteristics at a high-level within the same professional. The truth is that there are no effective tools to identify how great we really are in these skills. That's probably why it’s so difficult picking the ideal professional for the job. This is neither good nor bad. Bottom line: We were not born with a binary code that always allows us to go beyond expectations and break the simplistic view that we were destined to become something that we will be until the end of time. |
Project Management Is The Great Equalizer
|
In my project management career, I’ve been very fortunate to have worked on different projects all over the world. As with most things in life (like having a flat auto tire or forgetting to pay the electric bill), projects mirror the practical realities of life. One of the takeaways from those experiences has been the commonality of successful project management approaches no matter the geographical location of the projects. A key characteristic that I have observed over time is how projects and project management resemble a meritocracy independent of personal bias. Projects need to be complete with desired outcomes in a specific period of time. As one completes ever more large and complex projects, one grows in their career as a project manager. This career growth occurs regardless of the race, gender or other characteristics of the project manager. As with many other merit-based professions such as healthcare, aviation, athletics and science, the introduction of personal bias with project management would be detrimental to the completion of any project. That’s why project management as a profession is a great equalizer given its heavy dependence on the skills and capabilities of a project manager. In thinking about how project management is a great equalizer, I offer the following thoughts: 1. The project doesn’t know who is managing it. Projects are an interesting construct that is hard to categorize under the typical laws of physics; they don’t have weight, exhibit motion or temperature. Projects do have the characteristic of being a collection of activities and assets that need to be brought together to produce desired outcomes. In this regard, a project by definition is immune from any personal bias; it’s a matter of solving a three-dimensional problem using people, process and technology. A project manager needs to be skilled at resource, schedule, dependency and stakeholder management in order to solve for desired outcomes. The project itself does not prefer the personal background of the project manager; it awaits the proper project management disciplines to be employed in order to complete its required objectives. 2. Successful project managers find the best people. People represent one of the key factors in any project. When compared against process and technology components, the acquisition of the best people plays a more significant factor in the success of any project. However, the acquisition of people for a project also poses the possibility for personal bias. As a project manager, you have to be able to find the best people for the project independent of subjective perceptions. A CEO of a global company once said it took him 20 years to get a point where he could identify good people more than half the time. My observations of project managers early in their careers bear this out; they tend to be more subjective in selecting resources that they like and perceive would work well on their team; read this behavior as easier to manage. The more experienced project managers more discreetly evaluate competencies than subjective factors; this is key, as no matter the personal affinity or how easy (or difficult) the person is perceived to manage, the most critical dimension of people for a project is their competencies. 3. Project management metrics show no bias. One of my favorite quips about project metrics, especially when they are not favorable, is “You can’t beat the laws of physics.” If metrics show a project to be over budget or with late milestones, those are intractable project “laws of physics” that need to be addressed by the responsible project manager. To a great degree, project metrics are designed to not show any personal bias. They are a physical expression of project reality that can’t be influenced by personal factors of the project manager. Metrics are equal in every regard to serve as an unbiased foundation from which remedial project actions are taken. In my early years as a project manager, I have to admit I made every possible project management judgement error on my projects. Over time and with some valuable guidance from experienced project managers, I grew into leading ever larger initiatives. As part of that growth path, I observed that the most experienced project managers had left any notion of personal bias behind in their project management execution. Their focus on the core dynamics of a project, finding the best people and anticipating conditions that would lead to unfavorable metrics were key factors in their success. I welcome any commentary on the concept of project management being one of the purest forms of meritocracy that by design can’t rely on personal bias to achieve success. |
3 PM Lessons I Needed to Relearn
Categories:
Best Practices
Categories: Best Practices
|
by Dave Wakeman I just got back from taking a road trip, and while I was away for the month, I had my website rebuilt from the ground up. It turned out nicely and makes me look like I really know what I’m talking about. All kidding aside, having to put my website in the hands of an expert in web development taught me some lessons about project management that either I forgot or needed to learn. Let me share a few of them with you… 1. Being clear on the outcome you hope to achieve is crucial. At the end of the project, I debriefed with my web developer and she said that the nice thing about working with me is that I respect her work and don’t micromanage. As we continued talking, I realized that the reason I didn’t micromanage the project was because I was pretty clear in the project brief with exactly what I needed to achieve and what success looked like to me. Due to that, I was able to give her clear instructions and allow her to do the work I brought her in to do. In managing projects, all of us should be aware that if we spend a lot more time at the start of the project being clear about the results, we are likely to need to spend less time micromanaging or “handling” things during the project. 2. Communication is key. I’ve been talking about the people aspect of projects since I started writing this column back in 2012. In doing a project to rebuild myself under constraints imposed on me by the pandemic, I remembered the importance of clear communication. In the past, I know that I have written that the keys to successful communication are for your messages to be:
Over the years, maybe I’ve been guilty of getting away from those three principles, but I was reminded that these are essential communication qualities and that it is good to keep them in mind—especially when managing remotely. 3. Let experts be experts. One of the key ideas in my project management talks and writing is that as the leader, you can’t be the smartest about every aspect of your project. That’s why you work so hard to build strong teams. As often as I remind myself, I know that I can still slip up and throw out bad ideas. It causes two problems when I do this:
Strangely, my website project came together very well and I managed to keep myself from micromanaging the whole process. I was reminded that as a leader you have to:
What do you think? Let me know in the comments below. |
4 Signs You’re a Micromanager in Your Projects
|
By Yasmina Khelifi, PMI-ACP, PMI-PBA, PMP Are you a micromanager in your projects? Of course not! (Who would answer “yes” to this question?) However, after 20 years of work experiences with several managers and project managers, I’ve met micromanagers—and I was also one of them. Let’s review some language that reveals repetitive micromanagement behaviors observed during my career… 1. “I want to help you.” A few years ago, I had a micromanager. He was full of good intentions and always wanted to help me. He liked to brainstorm together, whereas I needed to brainstorm alone first and then share with the team. Without knowing it, he was stymying my creativity and motivation. I tried to explain to him I preferred to work independently and that I would come to him when I needed to, but he was offended by that as he wanted to help—and at the same time know it all. Ultimately, although the work was interesting, I left the team. His help was counterproductive. I’ve also proposed (even insisted) offers of my help to colleagues; now I try to refrain from doing that, remembering that manager. 2. “You are responsible for this work package—it would be good to do this…” I worked with a very competent technical project manager who wanted to know the details of the work. He once assigned me the management of a study with external stakeholders. He delegated the work package to comply with good management rules—but couldn't help interfering because he had a precise idea on how to do the work. I asked him if he wanted to manage it himself. My question waked him up, and he was less intrusive. When I managed my first software project, the sponsor wanted to know everything. He asked me questions, which I transmitted to the software engineers. They answered them reluctantly, complaining that we should let them define the way they wanted to implement the product. They considered it a lack of trust, which generated conflict. 3. “Don’t forget to ask her to call us if she needs more information.” Some project managers also told me: “At the end of the email, don’t forget to mention that we can have a conference call if more information is needed.” I thought in silence: “Don't you think a professional who needs more information will call? Do we need to add this sentence?” (Or another sentence about an email sent to a top manager: “Are you sure he transmitted the email we sent to him?”) This excessive control translates into wordy emails that don't bring value—and it increases our stress. 4. “Copy me on all emails.” In the software project mentioned above, I also wanted to be copied to all emails, anxious about missing any information. I didn't read them all, but I didn't ask to be removed from them. It gave me the illusion of knowing all about the project. Getting out of the micromanagement trap
The way to get out of this trap that we can all fall into is to honestly express what you need to work efficiently and healthily—and also express what triggers frustration and stress. You have no guarantee that sharing this will solve the situation, but it will help avoid frustration from building up and bursting out. We want to share our work experiences and help others avoid the traps and mistakes we've gone through, but making mistakes is part of the learning process. In addition, explaining these things to a seasoned project manager may be perceived the wrong way and come across as hurtful. Mastering how to help your team without micromanaging is a top competency in the hybrid world. What other micromanagement behaviors have you observed (or exhibited)? How did you deal with them? Share your comments below. |











