What is your project management familiar?
| Familiar - Noun, a supernatural spirit or demon, often in the form of an animal, supposed to serve and aid a witch or other individual. Project managers frequently wish that they had a trusted right-hand person who could help them out of challenging situations but why not broaden our imagination to think about the benefits of our multi-legged friends? Dear reader, before you start worrying that I have lost my marbles, fear not, this is merely a Gedanken experiment to help you gain a deeper understanding of yourself. Let's consider a few of the ones which came to my mind. A dog A canine will sacrifice itself if you are about to be thrown under the bus by an untrustworthy stakeholder and will cheer you up after you've experienced a rough work day. But you must also remember that dogs don't lead long lives so this might not be the best familiar if you are working on a long project. An elephant "An elephant never forgets" goes the cliche, so just imagine the benefits you'll gain by not having to document much of the information generated by your projects. Elephants are also able to carry a lot of weight which means that they could help you better bear the burden of a complex project. Unfortunately, they also generate a lot of waste so you might find yourself spending too much time cleaning up after your familiar. A cobra The swaying motion and spectacle markings on the hood of an alert cobra can be hypnotic which might be just what is needed to help you sway the attitude of your stakeholders. Cobras can't be tamed so you might have to constantly protect yourself from being bitten. A fly A fly has compound eyes which enable it to see the world in a completely different manner than we can. This could be extremely helpful when trying to understand a decision or issue from multiple perspectives. Just imagine the benefits of having your very own "fly on the wall" - think of all those hidden conversations which you will now be able to eavesdrop on! Unfortunately, one fly looks very much like another to an untrained eye so you could end up accidentally swatting your familiar. A pig Pigs are among the animal kingdom's smartest animals and have a phenomenal sense of smell. A pig could help you sniff out untruths faster than a lie detector could and when the going gets tough, your familiar might save your bacon. A bear There's no doubt that a bear could be a formidable ally to have your back in challenging meetings but do you really want a familiar which will sleep for almost a half year at a stretch? So if you were granted the wish of having an animal familiar what would it be? "Man is the only animal that blushes, or needs to" - Mark Twain |
A menagerie of project management myths
| Those of us who have been managing projects for a few years seem to run into the following myths and misconceptions on a sufficiently frequent basis that I felt it might be of value to consolidate and publish a few of them. Project management competency is about learning tools and techniques As with any other profession there are hard skills which need to be acquired to claim competency, but soft skills trump hard skills in project management every day of the week which ends in “day“. Planning is everything Yes, if you fail to plan, you plan to fail, but organizations don’t invest in projects to deliver infinitely detailed plans. Delivering business value in a predictable, consistent manner is the true value of project management. The right PMIS will solve everything! Did we learn nothing from the legacy of failed CRM, ERP and other enterprise applications? Automation makes a broken process break faster, so make sure you have defined, repeatable processes before purchasing and implementing a project management tool. The squeakiest wheel needs greasing first Stakeholders often follow Teddy Roosevelt’s advice to “Speak softly and carry a big stick“. If your focus is on the loudest stakeholder, you might end up making a detractor of a quiet, but highly influential one. Certification is crucial There are many qualified, competent project managers who are not certified along with many unqualified, incompetent practitioners who are. On top of that, just because someone is competent at managing one type of project within one organization doesn’t mean they will be successful at doing so in another or in a different domain. Caveat emptor. Agile only applies to software or systems projects Agile is a philosophy which can be applied to almost any project. Agile methodologies (e.g. Scrum) are relevant to specific project domains. The PMBOK is a methodology PMI’s PMBOK is a body of knowledge. The PMBOK Guide is a document containing a subset of the PMBOK. Neither are methodologies. Changes to scope are to be avoided at all costs Scope creep is bad. Managed scope change through reprioritization or formal change control is an expected outcome of the uncertainty present on all projects. I’ll close this week’s article with what I believe is the greatest myth of project management: lessons learned. Need I say more? (Note: These myths were original debunked in November 2015 on my personal blog, kbondale.wordpress.com) |
Don’t be a project management lemming!
| Given the current uncertainty in world markets, it is not a surprise that many investors are tempted to sell their investments at a loss and make like Punxsutawney Phil seeing his shadow, planning to re-enter the market only when the bulls start a sustained run. This is generally not a good idea as markets will eventually recover and the upside opportunities of buying during a bear run can be a worthwhile prize for those who are able to control the reaction to their fears. In the project management domain, you might have witnessed project teams panicking in the face of some looming crisis. Decisions made by the teams or their project managers under these sorts of conditions are usually driven more by emotions more than measured analysis. Fear is contagious – all it takes is one influential team member or stakeholder to succumb and it will spread like wildfire. We know that uncertainty and unrealistic expectations are as much part of the DNA of projects as they are stock markets so how can you help your team avoid a “fight or flight” response?
Rudyard Kipling – If you can keep your head when all about you, Are losing theirs and blaming it on you…Yours is the Earth and everything that’s in it |
Within sight, in front of mind!
| The sixth principle of the Manifesto for Agile Software Development is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation". We have all experienced situations in which our not seeing the person we were speaking with resulted in a misinterpretation of what was being said. When teams are composed of dispersed members who don't have the benefit of seeing one another face-to-face it takes longer for them to trust one another. It also can increase the volume of documentation required to create shared understanding. It should be fairly simple for teams working for a single company on small, low complexity projects to be co-located, but as project complexity, scale or the number of distinct delivery partners grows, multiple constraints including the availability of skilled contributors, financial restrictions or real estate limitations might prevent team members from working in close proximity. It is always a good idea for leaders to organize early and regular face-to-face opportunities to build trust within the distributed teams they are supporting. But is that enough? Augmented or virtual reality technologies have still not evolved to a point where we can accurately simulate being co-located, but using dedicated video conferencing facilities or even the webcams on our laptops can boost communication effectiveness. Such tools can provide us with benefits such as:
Albert Mehrabian's 7%, 38% and 55% rule about the relative impact which verbal, tone and body language cues have on how much we like someone is frequently misstated as representing the impact of all communications. But we should never forget that old saying: "Out of sight, out of mind". |
Self-organization is a progression not a transaction
Categories:
Agile
Categories: Agile
| A highly touted good practice for project teams is that they should be self-organized. Rather than rigidly following direction, team members possess the necessary enterprise savvy coupled with the awareness of what they do and don’t know about the project so that they can come up with the best way for them to plan and deliver the project’s scope. Self-organized teams are flexible so as changes occur to the project, they tailor their approach accordingly. They are also resilient in that while they will rely on each other’s skills, they aren’t crippled by the loss of any one team member and they are ready to onboard and assimilate new team members into their collective. This is in marked contrast to what is the norm in many companies. Projects are staffed with an emphasis on resource competency rather than how well they play together. Employee performance programs are geared towards recognizing individual accomplishments over the success of project teams. And enterprise governance policies lean towards favoring compliance with process over satisfaction of control objectives. Facing these sorts of constraints, is it any wonder that many teams exist in name alone? So when the decision is made to encourage self-organization, this change won’t happen overnight. Team members who have been used to looking out for their own interests over the success of a team will struggle with the shift to collaboration over consensus. They are also likely to lack the necessary confidence to effectively adapt practices and approaches to fit the needs of a given project. Some might follow an anything goes approach but reprisal for failed projects or broken organization policies is usually likely to be swift. Others might be paralyzed when they request governance bodies for guidance only to be told “It depends” or “You are smart and now we’ve empowered you, so go figure it out“. Self-organization is a progress, not a transaction. Coaching on appropriate leadership and team member behavior can help but rarely will there be sufficient coaches in place to address the demand, not can they be procured in a time or cost-effective manner. Definition and implementation of a development strategy based on a coach-the-coach model will be critical. For process tailoring, initial changes should focus on providing guidance for a limited number of choices where previously a single choice had been prescribed. As confidence and competency increases, constraints can slowly be relaxed. There have been some instances in recent history where prescriptive dictatorships have been toppled by foreign powers. With projects as it is with politics, if sustainable support mechanisms don’t get institutionalized by liberators before they leave, anarchy rather than self-organization is often the tragic result. (Note: this article was self-organized in July 2016 on my personal blog, kbondale.wordpress.com) |





