Easy in theory, difficult in practice

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


Recent Posts

Project management education should be like riding a tricycle

No bugs in agile?!?

Are you an enabler of bad project habits?

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

Show respect!

Project management education should be like riding a tricycle

Categories: Personal Development

A few years back, PMI implemented a number of changes to their Continuing Certification Requirements program which requires certified professionals to earn Professional Development Units (PDUs) over a three year period to retain their certification.  One of the key changes was that formal education-based PDUs must be earned from courses spanning the following three areas: technical project management, leadership, and business & strategic.

When we categorize the multiple competencies which are required to be a successful project manager, you’ll find the need to have a solid foundation of project management theory and practice, coupled with significant soft skills and sufficient domain expertise.

Some of you might argue that only the first two are a must, but the reality is that most managers will prefer to hire a project manager who understands their business processes and industry nuances enough that they can help identify risks and challenge assumptions and estimates.

These three categories map exactly to PMI’s requirements for the Talent Triangle. So while my initial reaction was to ask “Why fix what isn’t broke?”, upon further reflection, I believe this change is positive.

Many of the project managers I’ve met had focused their formal education on technical project management (e.g. risk management, critical chain) earlier in their career but as their experience increased, the focus shifted to enhancing soft skills or in gaining further domain expertise.

While any effort spent on developing oneself is good, there are risks in focusing development efforts on a single area.

If we focus on technical project management, we could learn about tools and techniques which we can’t apply within our work environment, and the investment is wasted. We could also run the risk of becoming dogmatic as there are very few technical project management courses that are 100% pragmatic.

If the focus is on soft skills development alone, we will certainly improve our ability to forge positive relationships with stakeholders and with our team members, but might lose track of how the tools and techniques within our profession are evolving and could come across as Luddites.

Finally, if the emphasis is placed on domain expertise, we would gain the respect and credibility of our customer and key business partners, but we run the risk of overstepping our boundaries with the analysts and other subject matter experts on our teams, and we might lose sight of the key tools and techniques required to be a successful project manager.

Recognizing that individual professionals are not likely to have the same level of interest across all three categories, PMI has only established minimum requirements for each. If someone is particularly interested in developing their soft skills, once they have earned the minimum PDUs for all three categories, they can earn the balance of their formal education-based PDUs through additional soft skills courses.

While a unicycle can be a capable means of transportation, a tricycle is more versatile.

(Note: I took the training wheels of this article in March 2015 on my personal blog, kbondale.wordpress.com)

Posted on: August 21, 2018 06:59 AM | Permalink | Comments (1)

No bugs in agile?!?

Categories: Agile

When a team is following an agile delivery approach and they have developed a Definition of Done (DoD) containing one or more criteria indicating that no defects are permitted in or as an outcome of completed work items, they should not have to deal with bugs escaping a sprint, and hence, the practice of documenting defects should become obsolete.

But how often does this happen in the real world?

Let's consider what's required to achieve this:

  • Pairs programming or other quality-focused development practices
  • Dedicated test environments covering the totality of the solution including all points of integration
  • Full coverage automated regression testing
  • Frequent (if not continuous) integration and deployment to support the progressive testing of completed requirements
  • The planning, definition and automation of test cases covering all of the requirements being worked on in the sprint
  • The ability to execute full non-functional testing within each sprint - security, performance, accessibility and localization to name just a few

If any of the items in the preceding list look daunting in your current context, don't panic - you are not alone.

Teams in organizations early or midway through agile transformation will work on products possessing none, some or all of the above prerequisites.

In the interim, here are three choices for those teams:

  1. If the defect relates to the natural evolution of the customer's wants and needs then it should be captured as a new requirement in the product backlog and prioritized by the Product Owner.
  2. If the defect can be resolved and properly re-tested within the current sprint, there is almost no value in documenting it. If there are significant time zone or geographic boundaries separating development and test roles, or if either the developer or tester are unable to work on it right away, the defect might still need to be captured somewhere to ensure it doesn't fall through the cracks before the end of the current sprint.
  3. If the team's DoD excludes the resolution of cosmetic or low severity defects, the defect should be added to the product backlog and prioritized by the Product Owner. This is an acceptable compromise for many lower maturity teams, but over time as their delivery capability improves, they will want to tighten up their DoD to prevent a progressive increase in this specific type of technical debt and to avoid their customer experiencing Death by a Thousand (quality) Cuts.

Linus Torvalds said it best "I'm generally a very pragmatic person: that which works, works."

Posted on: August 19, 2018 07:00 AM | Permalink | Comments (8)

Are you an enabler of bad project habits?

Categories: Personal Development, Project Management, Team Building

On occasion, you may have found yourself asking “If only my team members would do what I asked them to, I’d be able to spend time on more value add activities?”

Perhaps you are asking your team members to provide you with regular updates on the completion status of their assigned work. One of them neglects to provide this information by the requested deadline.

Being a collaborative project manager, you’ll meet with them to confirm that they understand the expected reporting timelines and may even ask them if there’s anything you can do to simplify the process so that expectations won’t be missed in the future. If nothing changes, you may commence nagging them or even escalate to their people manager in the hopes that things will improve. At some point, you may simply give up and start guess-timating how far along they are and using that instead of true actuals.

All that we have done is encourage a continuation of the behavior we were hoping to change.

Nagging or escalation will cause a good team member to disengage and estimating progress without their direct input will eventually come back to haunt you when other team members realize they can get away with this, or worse, your estimated progress reporting is proven to be wrong.

Hindsight is 20-20.

Having the team members as a group define the best way to report progress such that it wouldn’t impact their work while still meeting your reporting requirements might have avoided the current challenge. In that case, instead of you having to confront a team member for not adhering to your rules, you can engage the team in holding one of their own accountable to their rules.

But all is not lost – you can still use the same approach. In the next team meeting, let them know that some team members are struggling with the reporting requirements. Acknowledge the effort it takes to do this but also use it as an opportunity to refresh their understanding of how this information gets used and why it is so critical to have it provided accurately and in a timely manner. Show them a recent project status report or dashboard so they can see it live. Then, step back, and ask them to come up with ways to improve the process.

By involving the full team in the development of a solution, you will increase team members’ engagement and they are likely to demonstrate greater ownership of such administrative activities in the future.

When we point the finger at others, many times, the issue lies in the direction which the remaining fingers are pointing to.

(Note: this article was originally published in November 2015 to my personal blog, kbondale.wordpress.com)

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

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

Categories: Agile, Personal Development, Project Management, Team Building

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!

Categories: Agile, Personal Development, Team Building

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)

Music is the medium. Passion is the message.

- Herbie Hancock