Easy in theory, difficult in practice

by
My musings on project portfolio and change management. I'm a firm believer that a pragmatic approach to organization change that addresses process & technology, but primarily, people will maximize chances for success. This blog will contain articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Are you an enabler of bad project habits?

Are you a bulldozer or the boulder impeding your team’s progress?

Show respect!

Decision-making authority ain’t all it’s cracked up to be!

Risks in your project’s rear view mirror may be closer than they appear

Are you a bulldozer or the boulder impeding your team’s progress?

There are many aspects to the job of a project manager including a planner, a leader, and a conductor. However, one of the most important roles which a project manager can play is to remove obstacles to unleashing the creativity and productivity of their teams. Without that, the best planned project will still encounter delays and cost overruns.

Sponsors might introduce hurdles by imposing perceived constraints on the team such as due dates without clearly indicating that those are just targets. These can then reduce the confidence and increase the stress level of team members resulting in reduced velocity. Sponsors can also drag their heels on making key directional or funding decisions. A good project manager can avoid the realization of such risks through effective sponsor onboarding and ongoing engagement.

One of the many attributes of a stakeholder  is their ability to hurt a project. Good stakeholder management and appropriate use of political influence can help the project manager reduce the likelihood or impact of such behavior.

Team members might also generate their own obstacles. Economic downturns or company restructuring can generate a very natural sense of disengagement and paranoia which can sap productivity. An effective project manager can recognize the symptoms of this malaise and will implement the right actions to keep the team focused. Sometimes, the obstacles might be the working practices of the team – while a good project manager shouldn’t mandate how the work gets done, they should certainly provide their team with suggestions on how they can improve things and should support them in cultivating a team culture of continuous improvement.

But sometimes, a project manager can be the source of the worst roadblocks to the team’s progress.

Here are just a few.

  • Frequent requests for status updates
  • Pulling team members into meetings which they really don’t need to participate in
  • Complaining about stakeholders or the company itself
  • Not responding in a timely fashion to requests
  • Avoiding escalation or active conflict resolution
  • Hiding information which could be useful to the team’s work

There are many hurdles which can slow your team down – self-awareness and actively soliciting feedback on how you are doing could help you avoid making things worse!

(Note: I bulldozed through writing this article in June 2015 on my personal blog, kbondale.wordpress.com)

Posted on: August 14, 2018 06:59 AM | Permalink | Comments (8)

Show respect!

I've previously written about the importance of courage and discipline for agile teams, so let's review another important quality - respect. The Oxford English Dictionary provides two definitions for which are apropos:

  • A feeling of deep admiration for someone or something elicited by their abilities, qualities, or achievements.
  • Due regard for the feelings, wishes, or rights of others.

You might think that showing an appropriate level of respect is table stakes for anyone in any role regardless of their being an individual contributor or part of a team. That is true, but there are many dimensions to respect which need to be considered. Here are just five which I expect to see in practice in mature teams along with a few examples of how we fall short with each.

Respect for the organization's resources

Producing excessive or unnecessary documentation, inviting people to meetings who don't need to be there or not running disciplined meetings, and not regularly inspecting and adapting ceremonies or other delivery practices are just a few ways in which we needlessly squander the limited financial resources of our organizations.

Respect for our customer

Publishing out-of-date or inaccurate content in information radiators, failing to engage our customer in key ceremonies or the product decisions which they should have been involved in, avoiding the escalation of key blockers which our customers could have resolved or releasing low quality products just to hit a deadline are all examples of disrespect for these critical stakeholders.

Respect for our product

Skipping quality assurance procedures because we don't have time, ignoring our Definition of Done just to say we completed our sprint backlogs, kicking low severity defects down the backlog, ignoring technical debt and regular refactoring show that we don't really respect what we are producing.

Respect for each other

Making sprint commitments without full team participation, gold plating, showing up late for ceremonies, listening to make our point rather than actively listening, multitasking when we should be focused on what someone is saying, hoarding knowledge, not offering to help a team member when we are ahead on our work, and not having the courage to raise impediments which affect the entire team during daily standups or retrospectives demonstrate that we are putting our agendas and egos ahead of team success.

Respect for ourselves

Blindly following poor decisions without challenging them, making a sprint commitment which we know we can't achieve, refusing to ask for help when it would result in more efficient, higher quality outcomes and failing to invest in ourselves (e.g. personal development, sleep, exercise) are common ways in which we make it difficult to look at ourselves in the mirror.

Confucius said it right: Without feelings of respect, what is there to distinguish men from beasts?

Posted on: August 12, 2018 07:00 AM | Permalink | Comments (20)

Do you have a CRACK PO? (and a book review)

(If the title of my article for this week has you confused gentle reader, fret not - I'm just merging two distinct topics into a single post)

In 2003, Barry Boehm and Richard Turner coined the acronym C.R.A.C.K. (Collaborative, Representative, Accountable, Committed, Knowledgeable) to cover key characteristics of an effective Product Owner (PO). Unfortunately, some POs leave us with the perception that they might have been smoking crack!

Having worked with some POs who lack one or more of these attributes, I recently had an epiphany. I have always felt that there is no single delivery role which is the most critical, but my exposure to ineffective product management has convinced me that the PO is the hardest role to successfully fill.

Good agile leads (a.k.a. Scrum Masters) might be worth their weight in gold, but they are out there. If you aren't getting good ones the cause is not likely a lack of supply but rather blockers within your own organization (e.g. toxic culture, poor compensation) which are preventing you from attracting them, and in a pinch, contracting might be the way to go. Development team members are also valuable, but talent across most skill areas is available for the right price and with the right culture in place.

The challenge with the PO role is that not only do you need someone who has deep business process knowledge regarding the product they are supporting, but they also need to have well established relationships with key stakeholders who will influence product direction. While it is difficult to satisfy the first requirement, especially in those organizations where knowledge exists in silos, it is much more difficult to meet the second requirement. Simply parachuting in someone from the outside won't work regardless of how knowledgeable they might be about the domain.

So if you are lucky enough to have an effective PO, retain them at all costs.

On a different note, Eric Uyttewaal, asked whether I would be interested in reviewing his latest book - Forecasting Programs - Best Practices for Scheduling Real-World Programs.

I don't normally write reviews on my blog, but I have deep respect for Eric's knowledge of MS Project and his ability to make it able to stand on its head. Eric has written multiple books on effectively using the tool and given the dearth of guidance on using scheduling tools like MS Project to manage programs, I felt this was a worthwhile exception.

I was pleasantly surprised to see that the book goes beyond MS Project to providing general scheduling guidance for managing programs. While the examples and step-by-step procedures do focus on MS Project, they can be adapted for use with other scheduling tools.

Eric has done a good job of covering the analysis which a program scheduler might go through in deciding how to organizing their schedule, and I especially liked his Project Ideal and Constraint Matrix (PIC-Matrix) which can help a scheduler in deciding which scheduling approach to use given the primary expected benefit and primary constraint for a given program.

While there is guidance for scheduling projects following an adaptive lifecycle, Eric has taken a very narrow view of agile delivery. Sprint-based delivery might be the most commonly followed approach but it is not the only one. His compromise to find a happy scheduling medium by defining the content of a full backlog in detail so that work items can be assigned to all sprints and estimating all backlog items is not suitable for projects where requirements are expected to evolve dynamically. His approach to converting story points to effort hours is also concerning as there usually isn't a linear relationship between the two.

Eric's company develops and sells a number of add-on products to MS Project. While a certain amount of self-promotion is to be expected, I did find that the number of references to these products was more than I would have liked. In fairness, Eric does reference other third-party tools but generally positions his tools favorably relative to these competing products

I felt the book's greatest strength is the number of options which Eric has provided for scheduling programs which makes this book useful regardless of the maturity level of the practitioner.

Posted on: August 05, 2018 07:00 AM | Permalink | Comments (5)

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)

Posted on: July 26, 2018 06:59 AM | Permalink | Comments (19)

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:

  • Determining how engaged individuals are in the discussion. This can be especially helpful in ceremonies such as daily standups where it might be tempting for someone to tune out after they have shared their information. With everyone observing what each other is doing, the social pressure of not wanting to be singled out for multitasking might be enough to keep people's focus on what is being said.
  • When supporting a small distributed team, a facilitator might forget to call on silent team members. Seeing their faces makes it easier for the facilitator to draw them into the conversation, especially if the facilitator is picking up on a facial cue that a team member is concerned about the topic but seems to be unwilling to voice their concerns.
  • Enabling richer participation in voting, brainstorming, team building or creative activities. For example, if a decision needs to be made, a leader can ask for a show of hands, and determine how eager individual team members appear to be based on how quickly they raised their hands.
  • Helping team members to better support one another. It is very challenging to determine how someone feels if they are just communicating with us via e-mail, instant message or phone call. Visual cues can help you see that they are having a bad day.

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".

Posted on: July 22, 2018 07:00 AM | Permalink | Comments (12)
ADVERTISEMENTS

"You cannot prevent the birds of sorrow from flying over your head, but you can prevent them from building nests in your hair."

- Chinese Proverb

ADVERTISEMENT

Sponsors