Tag: Planning

The Agile PM—What’s the Big Deal about Commitment?

Written by Robert Galen on November 9, 2011. Posted in Articles. 5 Comments on The Agile PM—What’s the Big Deal about Commitment?

FEATURENov9th As I discussed in my last post, I’m a bit of an “odd bird” when it comes to certain aspects of coaching agile teams. For example, I like the notion of calling sprints either a success or a failure based on how the team swarmed around and delivered on their Sprint Goal(s). Many agilist’s struggle with using the word failure to connote team performance and delivery—some prefer avoiding it entirely.

Another term that causes angst within agile circles is the word commitment. Again, I personally like the word commitment. After finishing sprint planning, I like to ask a team to “commit” to their sprint goal. I like the visualization of going “hands-in” as a team—in formalizing their commitment. Sometimes teams even physically do it, which always makes me smile. I see commitment as being a bond within the team to deliver on a realistic goal that they determine as part of sprint planning. It’s a bond extended to the business and generates meaning and focus for the team. But again, I may just be odd and miss the true nature of commitment.

So, what does it mean to be committed?

Let’s start with a definition of the term. From wordreference.com I found the following definition:

the state or quality of being committed to a cause, policy, or person.

a pledge or undertaking

an engagement or obligation that restricts freedom of action.

Given that definition, project leadership is always looking for a team to commit to a project—to its target date/schedule, scope, and cost. They’re looking for guarantees from the team to meet the projects’ inception views towards completion targets.

On the surface that doesn’t sound bad—does it? Bringing it back to software development methods, there’s a perceived difference in how “committed” teams are in Waterfall variants vs. Agile variants (Scrum, Extreme Programming, Lean, Kanban, etc.).

Waterfall (is) Committed?

The thought goes that since teams plan their execution thoroughly in Waterfall, to a set of documented requirements, that when the project begins they’re in a clear position to fully commit to the project.

They’re committed to the date, to the scope, and to the costs they’ve estimated. And if there is any “negative discovery” along the way, the team will somehow figure out how to “suck it up”, working harder and longer to meet their “commitment”. No matter what happens along the way!

You’ll often hear management driving this behavior—reminding the team of their commitment and to work smarter and not harder. There might even be veiled and not so veiled threats, as to what might happen if they fail to…meet their commitment.

Agile (is not) Committed?

Conversely there’s a feeling that agile teams lack commitment. You hear this coming from nearly every executive, technology leader, and project manager who are adopting agile and struggling with forecasting project outcomes.

This comes from the basic tenet that teams commit to projects incrementally—as they gain more understanding of the work by implementing it in small chunks. That teams narrow in on their delivery target as they gain more understanding and collaborate with their customer. That teams can commit when they’ve made some progress and understand their delivery velocity.

In lieu of simply committing without knowing, agile teams focus on incremental delivery and incremental commitment; needing some time to truly understand the project complexity and their own capacity. Many misconstrue this prudence and transparency for a lack of commitment. But there’s also a truth to agilist’s struggling with the term.

nov9bob2

A quick diversion to the Scrum Guide

Ken Schwaber and Scrum.org publish something called the Scrum Guide. They recently (2011) published an update to the Scrum Guide changing the language used to reflect the team posture at the conclusion of Sprint Planning. Previous language had used “commit”, as in the team would “commit” to the work they identified and planned as part of their sprint.

The updated language changed the word “commit” to the word “forecast”—here’s a copy of the language change that I copied from the FAQ on the Scrum.org site –

Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.

This was one of six changes or adjustments that were made within the guide. I bring it up because it amplifies a common reaction in the agile community to the word commitment. At my core, I don’t understand the issue. It’s just a word.

Back to Waterfall vs. Agile Commitment

So are Waterfall teams more committed than their Agile counterparts? In the use of language around project targets and scope, it certainly appears so. But let’s get real. Waterfall projects rarely meet their commitments. I rarely do this, but I’ll bring out some statistics to make the point…

According to the 2009 Chaos Report examining the success rate of IT projects found that – 32% of projects succeeded, 44% were challenged or failed to meet some project goals, and 24% failed completely.

The key point here is the assumption that these were committed teams, yet literally 2/3 of the projects failed in some capacity. So I contend that commitment is simply a word. Not let’s look at commitment from a different angle—probably the right angle.

The Real Nature of Commitment

I don’t think team commitment comes from a methodology or a planning process—particularly for highly complex, technology-driven projects, with tremendous up-side risk because your teams are creating novel solutions to your problems.

Commitment is created by many factors and I don’t pretend to be an expert on it. However, it seems to me that some of the following are crucial to support an environment of commitment—

Teams commit to work that they have planned and estimated themselves; factoring in their true capacity and not influenced by unrealistic or artificial targets from their managers or corporate leaders
Teams commit to a compelling leadership vision, which leads to understanding project goals, determines strategies, and ultimately measures success
Teams commit to each other; so fostering an environment of teamwork, mutual accountability, trust, and professionalism
Teams commit to exciting and meaningful work; so communicate the ‘why’ and ‘impact’ of their work to inspire them
Teams commit to solid leaders—leaders who trust them to do their jobs and who provide sufficient support for them to succeed
Teams commit to doing good work. Work that balances competitive delivery against solid designs, creativity, work-life balance, and high quality
Teams commit to providing total honesty and real-time transparency so that their leaders can make congruent adjustments; to leaders that can “handle the truth”.

Wrapping Up

So I still like to instill in agile teams that Sprints can either “Pass or Fail” depending on their efforts and behaviors and results relative to their sprint goal. And yes, I do expect a team to “Commit To” their plan to meet a sprint goal that they’ve established with their Product Owner.

I feel it’s not the word that is the problem. Instead, the question is—does the environment support the team in the areas I mention above in meeting their commitments? Point being—I don’t see commitment as a team only condition. I think the organization needs to establish a culture and an environment where commitment is supported. Where discovery and adjustment is supported, where honesty and transparency is honored, and where failure is tolerated.

If you have an environment that isn’t supportive, then yes, I can see changing the term and not using it. In that environment, then “forecast” would be a better term…as would dysfunctional. But I’m tremendously disappointed in the organization that can’t make congruent commitments across their teams and then deliver on those commitments.

So call me committed to An Environment of Commitment…

Till next time,

Bob

Don’t forget to leave your comments below.

References

Top 10 Agile Phobias – http://www.slideshare.net/visuri/agile-phobias
Chaos Report reference – https://www.projecttimes.com/wp-content/uploads/attachments/chaos.pdf
Scrum Guide reference – https://www.projecttimes.com/wp-content/uploads/attachments/Scrum%20Update%202011.pdf
Wonderful article on Estimation, Prediction, and Commitment – http://tynerblain.com/blog/2011/08/09/agile-estimation/

How Should We Set Project Goals?

Written by Lisa Anderson on November 2, 2011. Posted in Articles. 6 Comments on How Should We Set Project Goals?

FeatureNov2nd As the headlines on the Wall Street Journal and business magazines are increasingly concerned about the economy in today’s new normal, businesses are re-thinking their business plans and searching for opportunities to increase profitability and cash flow. In my experience, the ones who will be thriving not only in a typical business environment but also in today’s new normal are the ones that put together plans, translate those plans into business, department, individual and project goals, and then execute effectively. Goal-setting is a vital component of this process.

So, how should we set goals? There are several keys to effective goal setting: 1) Tie the goals to the business strategy and plan. 2) The goal must be a stretch yet achievable. 3) The goal must be measurable.

Tie the goals to the business strategy and plan – This sounds obvious; however, in my experience, the two do not necessarily seem to relate, or it is unclear how they relate. Each team, department, individual and project team needs to understand how their goals fit in with the big picture – and their value to the business and their team.

There are very few employees who do not care to contribute to the success of the organization. Most would love to understand how their piece of the pie contributes to bottom line results, and it can provide an incredible source of motivation – vastly better than the approach of “do it or be fired” type messages.

For example, when I worked with a company who had to dramatically reduce costs in order to compensate for the increases in oil and gas prices in order to meet their investment bankers’ objectives (and therefore provide value to their customers who were the real motivation of the employees, since many of their customers were people similar to their grandparents or the ‘little old lady next door’), the key to the successful approach was having understandable goals. The employees were not onboard with seemingly investor-specific goals until the leaders tied the goals to the business strategy and customer needs, explained the whys behind the goals, and aligned the goals with the efforts of the project teams. Then, suddenly, it was in the best interest of the project team to achieve the goals.

The goal must be a stretch yet achievable – In my experience, I’ve seen many examples of obviously unachievable goals communicated. Unfortunately, as soon as the project team, department or employee receives an unachievable goal, motivation is lost. Often, even worse, it is replaced by fear, which can be quite distracting to making progress towards the goal. For example, when a project team is concerned about negative consequences, they often redirect focus from achieving the goal to how to avoid possible negative consequences.

Although preferred to a completely unrealistic goal, a relatively easy goal also falls dramatically short of providing an effective tool in driving business results. This can also become common in organizations that have a fear-based culture because the fear of not achieving the goal is overwhelming that it is tempting to sandbag goals. Unfortunately, an easy goal does not provoke brainstorming or teamwork.

On the other hand, when an achievable yet challenging goal is communicated, it can become the ingredient that brings the team together with a common purpose. And, many times, it results in increased teamwork and motivation.

The goal must be measureable – At the risk of stating the obvious, if the goal is not measurable, how do you know you achieved it? Many times, people struggle and struggle to try to make every goal measurable with numbers. Don’t sweat it – measurable doesn’t have to correlate to numbers. Although numbers are certainly one easy way to measure progress (such as reducing costs by $2 million dollars), not all goals lend themselves to pure numbers. For example, maintaining quality standards while reducing costs is a critical goal. In some respects, it can be measured with numbers (parts per million); however, customer feedback is just fine as well. Take a step back and think about how to measure goals in a way that makes sense for your business.

Setting goals doesn’t cost money; just time, and yet it can result in a significant return on investment for your business, project team or employee. Why not put some thought into how to set project goals?

Don’t forget to leave your comments below.

Scheduling 101: Remember the Basics

Written by George Pitagorsky on October 26, 2011. Posted in Articles. 4 Comments on Scheduling 101: Remember the Basics

Unquestionably scheduling is a challenge in just about any project. It becomes an even greater challenge when requirements change and resources are shared amongst multiple projects and between projects and operational activities.

My first project management job was on the Polaris project. A huge program but one in which most of the resources were dedicated full time and priorities and scope were stable. The hardest part of scheduling in that project was effort estimating and accounting for risk.

Since then I have found myself involved with projects in which resources are shared, there is little or no multi-project resource management and in which clients and users are up to their necks with day to day work so getting them to take part in requirements definition, decision making, testing and roll-out activities involves prayer, threats and the like.
So how do we schedule under those adverse conditions?

Well, one choice is to not schedule at all. Just do the work and finish when you’re finished. In this mode, frustration and escalation as well as diligence and commitment are the drivers for getting the job done. Sometimes projects never get done at all, staying on the back burner forever.

This is not my first choice. Like many who find themselves managing projects I want a bit more control. Clients and executives want to know when the results will be ready.

I have pretty much given up on certainty (uncertainty and impermanence are the only certainties). No amount of the best scheduling is going to provide a guaranteed end date. But, some reasonably accurate sense of “when” is needed and possible. That’s the message we need to get across to stakeholders and ourselves.

The key is realism. Begin with a solid sense of scope and a sense of how stable its definition is. Then create an estimate of how much effort is required. You’ll know this based on having done the work before and by breaking the work down into manageable chunks and estimating the chunks. If the project is unique, chances are many of the tasks are not that unique. Breaking the work down will enable you to identify the uncertainties and do a better job of estimating. If the project is like many others you’ve done before, life is easy. Do a top down analogous estimate. For tasks that have long lead times or are being done by people who are not effectively accountable (for example outside auditors, permit grantors, etc.) Build in a cushion.

As we know from basic training in PM the next step is sequencing to identify which tasks can be done in parallel and which must be done serially.

Next comes the hard part, resource allocation. If you are in an environment that maintains an accurate picture of how resources are allocated then this part is relatively easy. You can see who’s available when and schedule accordingly.

If on the other hand you are among the many without such an advantage you must be careful to estimate resource availability. Don’t fall into the trap of creating a schedule based on wishful thinking (or non-thinking). If you and other resources are bouncing from project to project to operational activities and back, build or if resources like clients, senior managers and end users (yes, these are project human resources) are hard to pin down for meetings and their task durations, then build contingency into your schedule. If you can, minimize interruptions and schedule projects or tasks so that they can be done without unnecessary starts and stops. Don’t be afraid to expand the schedule to accommodate multi-tasking, if you cannot get dedicated resources.

Manage risk. Keep in mind the difference between what is most likely to happen as opposed to what you would most like to have happen.

To account for uncertainty, use buffers or contingency funds rather than elongating individual tasks. At the task level, it is best to pin performers down to a specified target date. On the project level, it is realistic to expect completion within a range. Use contingency funds to manage task slippage and expectations.

Remember, scheduling is a means for managing expectations and performance. Make the initial schedule realistic and aggressive.

Be courageous. Don’t cave in to demands to set a target date that you know is a pipe dream. Adjust the schedule as actual performance and current perspectives dictate.

In the end, scheduling, and planning in general, does not determine the project outcome. The plan sets a direction and approach. They provide the map we use to determine if we are on course. If we are not on course we adjust. If the map is inaccurate we change it.

Don’t forget to leave your comments below.

How do you Implement Lean for Project Management

Written by Lisa Anderson on October 19, 2011. Posted in Articles. 8 Comments on How do you Implement Lean for Project Management

FeatureOct19 There’s no doubt that there is a vast amount of interest in lean principles. I’ve had multiple client requests – both ones who are interested in doing the latest and greatest program that they think might be the answer to “all their issues” and those who are interested in implementing culture change. I find that those clients who view lean as a culture change and are focused on long term fundamentals leapfrog the rest with bottom line results.

In today’s new normal business environment, sales are lackluster and resources are scarce yet customers expect more for less. Thus, the traditional avenues to success will no longer yield the same results. Instead, we must try new approaches and “think smart” to thrive in the new normal business environment. As project results can be a significant contributor to the bottom line, there is no better time to think about how to succeed in new ways. Why not incorporate the lean concepts that make sense to project management?
In my experience as a business consultant, a not-for-profit leader and a former VP of Operations, I’ve found that there are several lean principles which align with project management success. The top three include the following: 1) Focus on the customer. 2) Eliminate waste. 3) It’s all about the people.

Focus on the customer: Similar to implementing lean in manufacturing environments, first take a step back and think about the customer. Who is the customer of your project? Or, said another way: who will benefit from the project?

For example, one of my client projects is focused on reducing the past due metric. In this case, the customer connection is obvious – the fewer customer orders which are past due, the better service the customer will receive. Yet, even in this case, truly understanding what the customers’ value is important. Would the customers prefer a delivery date that is achievable and reliable or would they prefer a shorter lead time with less reliability? I’ve yet to work with a client who didn’t have customers who value different aspects of service higher than other customers. Find out and optimize based upon what each customer values.

In another example, another client project is to implement an inventory management system. Who is the customer? There could be several: The end customer will likely receive better service with improved inventory accuracy. The CEO will likely improve profitability as the inventory management processes are optimized. The CFO will be much better equipped for a financial audit. And the list goes on. Although it is helpful to brainstorm all the benefits, it is vital to understand which is of value to your customer.

Eliminate waste: There is a plethora of waste in project management. First, look for waste. Taking a step back, since it’s unlikely we’ll be looking for machine waste in project management, we should think about the best definition. I like the following – waste is that which doesn’t add value to the customer (and that which the customer is willing to pay for).

It is interesting how often we become used to waste and don’t see it anymore. Thus, you need to put on a new pair of glasses to see the waste all around you. Can you accomplish the project in a fewer number of steps? Are you following up on every task or focusing attention on the critical path? What will provide a return on investment? Are you asking the project team for input and ideas to eliminate waste?

It’s all about the people: Last but not least, those who succeed with lean initiatives understand that it’s all about the people. In essence, it is not an event; it is a culture change. Do you engage your people in the project? Do you ask for their input? Do you explain the project scope and its value to the organization? Do you do what you say you’ll do? I find this is much harder to do than it sounds yet it is a secret to unleashing your project talent. In my experience, an exceptional project team with a so-so project will beat a so-so project team with an excellent project every time!

Implementing lean for project management doesn’t require cash, capital or extra resources yet it can ensure that your project is delivered on time, on budget and with dramatic results. Although it is a good idea anytime, it is a must in today’s new normal business environment.

Don’t forget to leave your comments below.

Five Uses for a “Dead” Issue Log

Written by Kiron Bondale on October 19, 2011. Posted in Articles. 4 Comments on Five Uses for a “Dead” Issue Log

I couldn’t surpass Simon Bond’s volume of suggestions, but Issue Logs can add value beyond a project’s completion! Although you may be more likely to consider schedules, financial plans or even risk registers as useful post-project artefacts, here are a few reasons to consider doing more than just archiving those issue logs.

Improving operations: A good practice in project closeout is to transfer all open or on hold issues to the team that will be responsible for supporting the project deliverables in their operational state. However, even the data related to closed project issues can help with resolving operational challenges – troubleshooting methods, workarounds that might have been used during the project for expediency purposes or key contacts are a few examples of such useful information.
As I wrote in the article, Quantifying Risk Management Benefits, by reviewing issue logs immediately after a project has completed, you can glean candidate threats to future projects. You can also harvest quantitative impact data and gain insights into how effective specific issue management strategies were.

Helping to develop a Risk Breakdown Structure (RBS): An RBS can be a valuable input into risk identification activities, but to develop one that reflects the relative severity of different threat categories, past project issue logs can provide empirical evidence on issue frequency and impacts.

Proactive identification of portfolio-wide threats: Analogous to the rationale used by security agencies use for sifting through and analyzing terrorist chatter to avert impending attacks, analyzing issues across projects can help to identify significant systemic threats.

Resource evaluation and development: While the normal artefacts in a project can provide data to help resource managers understand how their staff perform under normal conditions and expectations, issue logs can provide insights and supporting evidence into how the same resources deal with unexpected situations. This information can help during performance evaluation time but can also be useful to identify which staff may be better suited to troubleshooting tasks.

Harvesting and distilling operational process assets requires effort, and such post-project activities may necessitate the services of a PMO or PM community of practice (as the project team will likely have moved on to their next project), however, “Those who cannot remember the past are condemned to fulfill it”.

Don’t forget to leave your comments below.