Easy in theory, difficult in practice

If you are sensing a theme here, you probably are.

After writing about the importance of courage for project managers and team members last week, I thought I'd cover another important characteristic, especially for those working on projects which follow an agile delivery approach: discipline.

Merriam-Webster offers a number of definitions for discipline including a few which I'm not overly fond of such as "Control gained by enforcing obedience or order" and "Punishment".  Neither of these sound well aligned with an agile mindset, do they?

However, the following two definitions hit closer to the value of discipline for agile teams: "Orderly or prescribed conduct or pattern of behavior" and "Self-control".

So how do agile teams demonstrate these orderly patterns of behavior and self-control?

Some are obvious:

• Showing up on time for ceremonies while also ensuring that they add value
• Updating Kanban boards or other information radiators in a timely manner such that they can be trusted by stakeholders as an accurate source of delivery knowledge
• Adhering to the team's Definition of Ready and Definition of Done unless there's a good reason not to do so for a given work item
• Self-awareness of bias and being sufficiently mindful to not act on impulse
• Making sure that product knowledge (e.g. training and support documentation) remains current

However others are more subtle:

• Resisting the temptation to gold-plate
• Demonstrating courage in coaching senior stakeholders when they want to add more work than the team can complete at a sustainable pace and in a quality fashion
• Avoiding early commitments
• Not completing another team member's administrative work for them unless there is a valid reason for their not doing it themselves
• Granting a team or a team member the freedom to fail

If there is one lesson I learned from my brief foray into the world of martial arts, it is that self-control is critical to success. Given the parallels which get drawn between learning a martial art and becoming agile (e.g. Shu-Ha-Ri), it is little wonder that self-control is important for successful agile delivery as well.

A stealth project is an initiative that was never formally sanctioned or approved. This is not a value judgment - many stealth projects are able to deliver worthwhile business outcomes, but at what cost?

Stealth projects have been portrayed as being one of the Four Horseman of the Project Portfolio Management Apocalypse. So why do they survive (and even thrive!) in many organizations?

A stealth project usually emerges when a customer knows that their request will not be addressed in a timely fashion and leverages their position, influence or relationships within the organization to get the work done.

Likely causes for this perception are:

• The customer may feel that the request will not be perceived by the governance committee or decision makers as being as worthwhile or as urgent as other requests that are more likely to be approved
• The customer may feel that the work intake process (the method by which requests are submitted, evaluated and either approved or rejected) is too onerous

Another possibility is that the customer may simply not know any better. They may have been used to going to their "favorite" resource in the past to get things done, and even if a work intake process has been implemented they may be unaware of it or be purposely ignoring it. We tend to repeat past behaviors that resulted in desired results where there were no negative consequences. If there were no repercussions in the past for not following proper work intake practices, this behavior will persist.

So why should we care about stealth projects?

• They consume human and financial resources that should have been utilized on officially approved and prioritized initiatives. No organization today has the luxury of infinite resource capacity, so there is always an opportunity cost incurred by turning a blind eye to stealth projects.
• They may not be executed following all required compliance policies and practices. When a project is initiated as a stealth project, it is a reasonable assumption that quality or regulatory assurance practices might have been missed. The result could be that the deliverables from the project incur a heavier operational support or regulatory compliance burden than those of properly sanctioned and managed projects.

How can we identify stealth projects?

Organizations that have successfully implemented time capture systems have an advantage, but it could also be as simple as managers knowing what their teams are working on, and for the management team as a whole to be committed to identifying and exposing stealth projects.

The outcome should not solely be punishment of the originators of these projects. In many cases, the customer may be unaware of the proper work intake process or may be highlighting a scalability or flexibility issue with the process.

To weed out stealth projects, a well communicated, flexible and scalable work intake process coupled with management commitment to the process is essential. However, this needs to be balanced against fostering a culture that encourages the brainstorming and submission of creative, innovative ideas.

(Note: this article was originally written and published by me in November 2009 on ProjectTimes.com)

The classic difference between theory and practice is admirably illustrated by some of the principles reflected in the PMBOK Guide when we compare them with the organizational project management reality that we are often faced with.

A good example of this gap relates to the Project Charter.

The PMBOK Guide correctly identifies this document as the key trigger that formalizes the existence of a project and that vests a project manager with the authority to apply resources towards the achievement of the project’s vision.  The PMBOK Guide further clarifies that while the sponsor is responsible for issuing the charter, they might delegate the actual effort of developing it to the assigned project manager.  The charter achieves almost the same level of importance as a foundation document for a religion.

If only it were that straightforward – in many organizations, resources might be busy delivering scope and budget might be expended before a charter document is approved and issued (if it ever is!).  The complaint I heard from one practitioner this week was why should the PMBOK Guide be so far removed from the way projects are managed in “the real world” – in the context of learning about how to manage projects, it seems academic to be memorizing theory.

On the surface, this seems like a valid argument – if the majority of organizations that a typical PM is exposed to are at a very low maturity level, what is the point in going through the frustration of learning best practices that can never be applied. 

My take on it is that the PMBOK Guide provides a good vision of how project management should be practiced and each organization (and practitioner) could strive to improve their planning and execution capabilities using guidance from it or similar sources of knowledge. 

If the extent of our vision is a stone’s throw away, that’s as far as we will progress – once we visualize a goal that is much more challenging, we experience true growth.

This segue brings me back to the point of this article – committed project sponsorship has often been identified as a project critical success factor.  If you cannot get your project sponsor to engage sufficiently to issue or at worst to review and approve a charter during the honeymoon stage of the project life cycle, what luck do you expect to have when escalating a project issue or significant project decision to them?

(Note: this article was originally written and published by me in July 2011 on my personal blog, kbondale.wordpress.com)

When we think of the characteristics of a good team player, we tend to come up with attributes such as demonstrating selflessness, possessing empathy, or being a good communicator. While these are all critical to creating a high performing team, one trait of effective project managers and team members is the ability to do things which take them outside of their comfort zone. In other words, courage.

Why do I consider courage to be so critical?

Courage won't guarantee that right decisions will get made, but it might prevent some bad ones.

Presented with an unrealistic deadline to deliver fixed scope with fixed resources and budget, if no one demonstrates courage by raising concerns or by negotiating for a feasible commitment, the team might have just signed up for their very own real-life Kobayashi Maru scenario.

Perhaps a sponsor or other senior stakeholder is pushing for the use of a particular delivery approach for political reasons. If it is not the best fit for the needs of the project, it's rare that the accountability for this bad decision would fall on that stakeholder but it's more likely that the team will bear the brunt of the issues.

Maybe the business case for your project is no longer attractive. It might be safer to keep your head down and continue to deliver according to approved baselines, but wouldn't it be better for your company, your team and your own career if you were to bring this concern to the sponsor or other appropriate governance body?

Maybe your organization's project management methodology requires the completion of a particular artifact. No one on your team believes it adds any delivery or risk control value. If you don't have the courage to ask "Why?" or to seek an exemption, you've likely lost some credibility with your team members.

Courage preserves integrity by enabling us to operate with transparency

It's hard to tell your customer that there is a unrecoverable variance or other critical issue with their project. But if we candy-coat this message, or worse, avoid telling the customer entirely, the truth will out, and the fall out is likely to be much worse than if we'd summoned the courage to break the bad news in a timely manner.

Maybe one of your fellow team members is behaving in a manner which is irritating others. If we don't have the courage to provide coaching or constructive feedback sensitively but directly to that team member and give them an opportunity to respond, we aren't demonstrating respect for that team member or our team.

Courage enables us to grow

Whether your project is being delivered using an adaptive or a deterministic life-cycle, team members and your company as a whole will benefit if they occasionally work on activities which fall outside of their core specialization, if doing so benefits the team. Developing generalizing specialists will take support from both functional managers and from one's peers, but it also requires a healthy dose of courage for us to try something for the first time, knowing that we might fail. This applies not only to the activities performed by team members, but also the types of projects or work assignments we ourselves take on.

“Courage is the most important of all the virtues because without courage, you can't practice any other virtue consistently.” - Maya Angelou

Good project managers are usually in high demand so it can be difficult to convince senior management of the benefits of building in some downtime between project assignments.  You may also face resistance from PMs themselves if your organization tracks and evaluates staff based on utilization.

Beyond providing PMs with much needed vacation or opportunities for formal professional development, what are some of the value-add activities that you could use to convince the naysayers?

1. This downtime provides the opportunity to develop new organization knowledge assets (e.g. templates, lessons to be learned).  While conducting a lessons learned session or archiving project documentation are normal project closeout activities, it is hard to add the costs of making the output of these truly useful to the budget of the project.  Also, having a PM perform these activities immediately after a project avoids the memory loss that would occur if they were done much later.
2. If the organization does not have a staffed PMO, downtime after a project is completed could be used to enhance or refactor PM methodologies and practices.
3. Coaching is a key ingredient in cultivating good PMs.  PMs that are on the bench can be assigned to support more junior PMs by providing advice on key decisions, reviewing PM artifacts or by facilitating workshops.  This sort of “parachute” support is not a substitute for a long term mentoring relationship but it does help, especially in organizations that don’t have a formal process for supporting the development of PMs.
4. Helping sponsors exploit the benefits of their projects.  In the first few days after a project is completed, the sponsor might feel overwhelmed with operational responsibilities and while the PM’s role traditionally ends at closeout, their knowledge of the deliverables and the relationships they developed across the organization could be a valuable asset to achieving expected outcomes.

For the pessimists amongst us, the final rationale could be that creativity and enthusiasm are resources that can’t be continuously consumed without an opportunity for replenishment.  PMs are often drained physically and mentally at the end of a project, and this poses a very real risk to the next project they take on. 

By building in mini-sabbaticals between assignments, the opportunity is provided to de-stress while still adding value, and the gratification the PM receives from contributing the the development of other PMs or to their organization’s assets may be more fulfilling than what could be achieved by a few days off.

(Note: this article was originally written and published by me in March 2012 (likely from a golf course!) on my personal blog, kbondale.wordpress.com)