Author: Kiron Bondale

Annual Project Planning is an Anachronism!

Written by Kiron Bondale on October 17, 2012. Posted in Articles. 6 Comments on Annual Project Planning is an Anachronism!

Although its justification is usually tied to the budgeting cycle, it’s safe to say that an annual project planning cycle presents some serious flaws.

Significant effort is expended to have each functional area come up with its wish-list of projects. This process will usually include some quantitative and qualitative analysis to help support decision making. After this information has been gathered, the real “horse trading” begins to identify the short list that will proceed right away as well as those projects that are still important but won’t start until resources become available. It’s even possible that objective priorities are set for the project lists at both a corporate and functional area level.

Unfortunately, this prioritized list which is produced at great cost and elapsed time is just a model and like any model, if it is not kept current, it rapidly diminishes in value. It is very rare to find a leadership team that when reviewing their annual project list months after its creation would feel confident that the relative priorities and completeness of the list is accurate.

Changes in the external and internal environment drive the need for new projects, and those initiatives that had seemed worth funding earlier in the year are forgotten as new information emerges. To make matters worse, if work allocation and tracking practices are not consistent, it’s entirely possible that stealth work on divisional “pet projects” may be taking place which would further impact the quality of the annual project list.

While it would be ideal to mature planning practices in an organization to a more dynamic approach, this type of evolution can’t happen overnight. However, there are some incremental changes that could help to start the ball rolling.

Assuming the senior leadership team receives monthly or quarterly updates on the status of active projects, ask the following four questions once the active project status review has been completed:

Are all of the pending (i.e. not active or completed) projects on the annual planning list still valid, and are there any on this list that we don’t intend to start this year?
When are you intending to launch the remaining pending projects?
Are there any other projects that your staff are actively working on that are not on this list?
Are there any other projects that you intend to kick off this year, and if so, in what month/quarter?

The answers to these questions should enable the creation of a rolling one year planned project portfolio which would become a key input into project intake. When a new project request is submitted for consideration, if it is not on the planned project portfolio, the governance committee should be reminded of the priorities they would have been (re)set recently. While unexpected environment changes (e.g. “Black Swans”) might still cause disruption to the portfolio, this approach might help to make this situation an exception.

Annual project planning has been the norm for a very long time so one might feel that change is not feasible. However, organizations that won’t evolve are likely to appreciate Arthur C. Clarke’s quotation about the risks of complacency: “The dinosaurs disappeared because they could not adapt to their changing environment.”

Don’t forget to leave your comments below.

Projects ARE a Distraction for Functional Organizations

Written by Kiron Bondale on September 5, 2012. Posted in Articles. 10 Comments on Projects ARE a Distraction for Functional Organizations

FEATUREAug5th When managing projects within functionally-structured organizations it can often feel like a daily challenge to engage people managers effectively such that staff allocations are predictable.

Not only might the managers in such organizations be reluctant to make staff commitments, the true availability of your new team members are also likely to be subject to the ebbs and flows of operational work. To make things worse, it is rare in functional organizations that project managers have direct input into team member performance evaluations, so given that these evaluations are solely performed by the staff’s direct managers, it is a reasonable assumption that team member focus would primarily be on their day-to-day activities.
The manifestations of this could include any of the following behaviors:

Functional managers challenging or questioning project roles, responsibilities or activities for team members
Availability or allocation of team members changing frequently with little or no warning from the team members or from their direct managers
Team member substitutions with the project manager being the last to know
Project managers getting admonished for following up directly with team members on work status or progress
Absence or minimal participation from team members in project status meetings

You may have done a good job of explaining how the project’s success will benefit the functional managers & their teams, so it can be extremely frustrating when even basic cooperation is lacking.

A fundamental difference exists in how projects are perceived between functional organizations and balanced or strong matrix ones. While we might consider projects to be the medium through which positive change occurs, in functional organizations, they represent a costly diversion for staff. As the percentage of effort spent by a team on operational work nears 100%, the greater can be the challenge in engaging staff on project work.

This issue cannot be resolved by a single project manager or even by a PMO – the change needs to come from the functional teams themselves. The first step is acknowledgement – if you can help the management team recognize that project work will not diminish over time and that they should consider implementing approaches to reduce impacts to operational responsibilities, that’s half the battle won.

An approach to consider is rotational segregation of staff within existing teams. Depending on the volume of project work and the available capacity, one or more staff can be requested to focus on project work for a fixed period of time and once their project “tour of duty” is over, they will be rotated back to daily operational work. This avoids the divisiveness of permanently splitting a team, and increases the likelihood of knowledge transfer between team members.

Project managers might find people manager behavior perplexing in functional organizations, but this is another good scenario to apply Covey’s Fifth Habit “Seek First to Understand, Then to be Understood”.

Don’t forget to leave your comments below.

A PM’s got to know their limitations!

Written by Kiron Bondale on July 25, 2012. Posted in Articles. 6 Comments on A PM’s got to know their limitations!

While I wrote in “Today, my (PM) jurisdiction ends here!” that a project manager who focuses purely on the triple constraint without considering the organizational outcomes of their project is adding limited value, I’ve also worked with some that willingly operate at the opposite extreme.

This might be the behavior of a project manager who believes that the full accountability for the project’s success falls on their shoulders and that the best way to avoid being blamed is to take over all critical activities. This can also occur with junior project managers who are assigned projects that are within the domain of their past experience – it is too tempting for them to backslide into their “past lives”.
Another rationale could be if it is the reaction to an organization that suffers from low project management maturity. If sponsors, functional managers or team members abdicate their duties, a project manager might be faced with the choice of picking up the slack or letting the project suffer. What’s challenging is that even if the situation improves, the project manager might be very reluctant to let go.

It’s hard to define exactly when a project manager crosses this invisible line, so what are some of the warning signs that their manager could monitor?

Frequent negative or positive feedback on the project manager’s performance from project participants. You might be surprised by my inclusion of the positive, but in the case of a low maturity organization, excessively positive praise of a project manager’s “ownership” could be an indication of too much involvement!
Significant, sustained overtime on the part of the PM while other team members are able to complete their work within normal working hours.
Neglect for project administration or other “low value” duties – logs are not maintained, schedules are out-of-date, minutes from key meetings don’t get published.
As 80+% of a project manager’s role is communication, if they are spending too much time wearing other hats, communication consistency and quality is likely to suffer.
Excessive use of the pronouns “I” and “Me” instead of “We” when referring to the project. This might seem minor, but it can be indicative of the latent problem.
Premature departures of previously high performing team members. If a good worker feels that someone else is doing the job that they were assigned to do, they’ll likely prefer to move to a project where they will be able to shine.

While sponsors and team members may appreciate someone who is willing to roll up their sleeves when the situation demands it, if this behavior becomes the norm, the project manager will get blamed regardless of whether the project succeeds or fails. To avoid this, it’s best to ignore Clint Eastwood’s other quote “Now you know why they call me Dirty Harry: every dirty job that comes along.”

Don’t forget to leave your comments below.

Agile Projects are NOT Immune to Scope Creep!

Written by Kiron Bondale on May 30, 2012. Posted in Articles. 10 Comments on Agile Projects are NOT Immune to Scope Creep!

FEATUREMay30th One of the differences of agile practices when compared with waterfall is the incorporation of change as an integral component of the project as opposed to a threat that needs to be tightly managed or ideally eliminated beyond the planning phase.

Agile practices provide this flexibility by fixing other key constraints such as cost or time, and allow for scope change by allowing the project’s customer to modify the content and priority of items in the work backlog at regular intervals.

This differentiator is often communicated as one of the key benefits of agile methods — while true, don’t assume that agile projects aren’t subject to scope creep.
The normal entry point for scope changes on agile projects is at the end of sprints or iterations during the review of the product backlog at which time the customer would add new work items, clarify existing ones and reprioritize the backlog.

However, this is not the only way in which change can be introduced. Project team members could gold plate or even redo their work. The customer or other project stakeholders could also be influencing continuous change to the “what” or the “how” of the deliverables.

If these types of changes are not reflected as new items in the work backlog, the only indicator of the issue might be velocity metrics, which would illustrate that team productivity is dropping and that it would likely take many more iterations to complete the project.

So what are some methods that a project manager could employ to balance stringent scope control with a “free-for-all”?

Ensure that high-level iteration planning includes a determination of how many iterations are required to meet the customer’s minimal must-have requirements. Focus the team and customer on achieving this target, and then use remaining iterations as an opportunity to refactor and refine.
Work with the customer to develop a performance incentive plan for the team that balances completing work on time and on budget with meeting all of the customer’s requirements.
Track iteration velocity and if it drops or is well below expected levels, dedicate sufficient time during the retrospective session at the end of each iteration to help the customer and team members identify likely causes. These reviews could include looking at what was expected to be completed during the past iteration and comparing that to the work items that were actually worked on by team members, and how many of those were redone or significantly modified.

Agile practices are not a panacea, but with planning and careful monitoring it should be possible to “inoculate” your project against the impacts of scope creep!

Don’t forget to leave your comments below.

Avoiding the What the Customer Wanted Syndrome

Written by Kiron Bondale on April 18, 2012. Posted in Articles. 7 Comments on Avoiding the What the Customer Wanted Syndrome

Feature Apr18 32807816 XS You have likely seen some variation on the cartoon that illustrates the differences in interpretation of a customer’s requirements by various participants in a project (if not, click here) so you’d expect that there is a general understanding of how common this issue is and how to avoid it.

Unfortunately, this is another case of practice not aligning with theory. Most waterfall project methodologies utilize documents to provide the contributors for each phase of the lifecycle with knowledge of what the customer wanted. While we would normally hope to have a business analyst or similar role to ensure consistency of understanding and communication across all phases, in some cases, there may be no resource continuity and this knowledge is transferred purely in documentation form.

If we assume that each handover results in a certain degradation of the knowledge captured in the previous phase, the effects of this requirements corruption compounds the more steps we add. It is still common to find projects where there might be four or even more handoffs between the customer and the actual creator. The most likely outcome of this during product handover is a quality variance which will result in customer satisfaction, budget and schedule variance issues.

This is the rationale behind one of the key principles of agile approaches – make the customer an integral part of the project. Yet even on agile projects, one often sees an increase in the distance between the customer and the creators. This might be due to legitimate geographical or time zone limitations, but other times it is because of political or priority reasons. The “easy” answer in such cases is to start introducing proxies for the customer, thereby increasing the likelihood of expectation gaps. This gets worse in cases where the delivery organization outsources portions of the delivery process as there are likely to be even more hops introduced.

As project managers, we need to avoid the temptation to follow the path of least resistance – if the pushback in involvement is coming from the customer, it is important to have those “difficult” conversations to help them understand the risks introduced and to confirm the relative priority of the project deliverables. If resistance is originating from the delivery team due to concerns of constant requirements refinement or change, it may be worthwhile to review the outcome of projects where the customer had not been involved to prove the merits of an alternate approach and to explain how other project constraints (e.g. schedule, cost) can be fixed thus allowing scope to be flexible.

While six degrees of separation might be enough to connect you with Kevin Bacon, striving for zero degrees of separation between your project customer and your team might help to bring home the bacon!

Don’t forget to leave your comments below.