Author: Kiron Bondale

A Project Manager’s Mid-year Performance Tune-up

Written by Kiron Bondale on June 17, 2014. Posted in Articles. 4 Comments on A Project Manager’s Mid-year Performance Tune-up

For many companies, the month of June is when mid-year performance evaluations are conducted. I’ve often found it helpful to solicit feedback on my direct reports using start, stop and continue categories. This technique provides a team member with guidance on which activities they might consider modifying as well as encouraging continuation of positive behaviors.

Listing the common activities and behaviors being performed by most project managers which should be encouraged would fill multiple books. However, here is a much shorter list of do’s and don’ts which are worth reviewing as a checklist for your mid-year performance tune-up!

Start asking “Why?”. One of the most endearing, though at times most frustrating, traits of small children is their insatiable appetite for asking questions. As we grow up, we repress this natural inclination to question information being presented to us. On projects, not requesting clarification or justification can end up costing our project teams a miserable trip down the road to Abilene.

Stop imposing self-made limitations. Your project will have some real-world constraints – nine women can’t have a baby in one month. However, to quote Morpheus, when it comes to the most project constraints: What you must learn is that these rules are no different than the rules of a computer system. Some of them can be bent. Others can be broken. When faced with a decision or issue, to overcome linear group-think, it can often be helpful to challenge your team by asking “what if?”. A common example of this is with risk responses – as I’d written about in an earlier article, we eschew the avoid response as we are hesitant about challenging scope inclusions.

Start following good practices. We shouldn’t learn about tools and techniques such as earned value management, expected impact calculation, Delphi method and work breakdown structures just to pass a project management certification exam. While you may feel that your company’s project management maturity level is too low to enable the usage of such practices, follow the advice from the

Guide to the PMBOK and tailor their usage to the specific culture of your team and the needs of your project. If we wish to be treated like professionals, a reasonable expectation is that we should practice project management in a professional (i.e. not ad hoc) fashion.

Stop being a checklist PM. While it might appear somewhat contradictory to my previous recommendation, it is as bad if not worse to blindly following processes and practices. Some of the worst project managers I have worked with were extremely compliant with their organization’s methodology (the “what”) but demonstrated little judgement (the “how”). Whenever you find yourself falling into the habit of treating the project management lifecycle as being a linear set of steps or processes, just remember that uncertainty and uniqueness underlies all projects, hence taking the time to decide what is the most appropriate next step or practice is crucial.

Start sharpening the saw. In almost every other career path, professionals know the importance of continuing to develop their skills to stay current and to stay abreast of changes in their field. Perhaps it’s because project management has been an “accidental profession” for so many of us, but there doesn’t appear to be that same commitment to ongoing learning. How many of you take the time to thoroughly read all the articles in the monthly journals you receive from your project management associations? Personal development has to be more than just taking courses – after a point you will find diminishing returns in what you are actually learning. You may find you’ll get more out of mentoring a junior PM or participating in online discussions related to project management. Of course, this requires planning the (personal development) work, and then working that plan!

Stop being a pessimist. I realize the more experience we gain, the greater our appreciation for how tenacious and creative Murphy can be, but being a realist does not mean expecting the worst in every situation. I’m not advocating the opposite extreme of blind optimism, but let context be your guide. When your team appears to be dwelling on what could go wrong, you be the one person in the room who sees the cup as half-full. During risk identification sessions, when negative risk events are presented, think about the opposite situation and explore with your team how you might exploit such opportunities.

If you’ve taken courses on quality, you’ll be familiar with the 1:10:100 rule which indicates that the costs of prevention is significantly lower than the costs of inspection which in turn is much cheaper than the costs of external defects. Apply this rule to your own performance to keep your project management career running like a well-oiled machine!

Don’t forget to leave your comments below.

Project Managers & Business Analysts – Why Can’t We All Just Get Along?

Written by Kiron Bondale on May 4, 2014. Posted in Articles. 9 Comments on Project Managers & Business Analysts – Why Can’t We All Just Get Along?

You might disagree with me, but there is a greater co-dependency between the roles of a project manager and business analyst than with almost any other pair of project roles.

No doubt, a project sponsor is crucial to a project’s success and it is critical that a project manager establishes a positive, mutually beneficial working relationship with their sponsor, but once the project gets underway, most project managers will find themselves spending much more time with the business analyst.

Requirements are one of the most frequently cited sources of project issues and an effective requirements management process can go a long way towards improving project predictability. Given this, one would expect that these two roles would naturally work very well together, or at the very least, would go out of their way to ensure that they weren’t impacting each other.

Unfortunately, in many of the organizations I’ve worked with, this isn’t the case, and while it might be easy to chalk up a few incidents to individuals, the number of times I’ve heard complaints between the two roles indicates there’s something deeper at play.

From the business analysts, common complaints about project managers include:

Appear to be focused solely on cost or schedule constraints without also embracing the criticality of having good quality requirements
Demonstrate an unwillingness or inability to provide assistance in ensuring that stakeholders are attending and contributing to requirements gathering or review sessions
Don’t bother to read or understand high-level project requirements documents
Support or initiate scope change decisions without proactively engaging the business analyst

On the other side, I’ve frequently met project managers who complain about business analysts who:

Appear to have no sense of time or cost constraints when producing their deliverables or appear unable or unwilling to provide effort or duration estimates for their work
Produce requirements documents which are unusable by other project team members or which don’t address the customer’s stated and unstated needs
Appear to forget that the second word in their job title actually implies the task of analyzing, distilling and refining requirements as opposed to just parroting what’s been received from stakeholders
Become unavailable for the remainder of the project’s lifetime as soon as their requirements documents have been signed off

While individual projects might suffer as a result of such challenges, the greater long term impact is the erosion of the mandatory trust and mutual respect which needs to exist between these roles – this will result in chronic challenges to projects.
While these symptoms appear quite varied, they usually relate back to one of the following two root causes:

A lack of clarity regarding the responsibilities, drivers and expectations of each role, based on the context of a given project
A lack of alignment in the performance objectives or metrics for each role, based on the context of a given project

One might assume that through osmosis if not through formal training each would be quite aware of the other’s role. This is absolutely the case when one is speaking theoretically about the functions which each performs. I’ve rarely heard complaints when project managers are being educated about the roles, standard practices and responsibilities of business analysts or vice versa. Trouble often begins when one tries to apply the theory to a given project and this is why I’ve added specificity in the ending clause of both of these root causes.

It’s common practice for project managers to have a preliminary expectations “get and set” meeting with their sponsors – this is often done as a particular executive might not have played that project role recently, or may not have ever worked with a particular project manager before. There’s really no good reason why a project manager shouldn’t extend the same courtesy to a role as critical to project success as the business analyst’s.

This meeting provides both individuals with the opportunity to walk each other through the practices they intend to apply based on the needs of the project and to discuss expectations each has for the other’s role. By covering “rules of engagement” at the outset, a number of future disconnects could be identified and resolved before they begin to impact project performance or the working relationship between the two roles.

Joint conferences have been held for project management and business analysis for many years, and PMI has recently announced a new certification in business analysis. Both of these are evidence of how inseparable the roles are. By taking the time upfront to understand how each role will work on a given project, one can almost hear the Turtles: “Imagine how the world could be, so very fine, So happy together”

Don’t forget to leave your comments below.

Post-it Notes Just Might be a Project Manager’s Best Tool!

Written by Kiron Bondale on April 2, 2014. Posted in Articles. 6 Comments on Post-it Notes Just Might be a Project Manager’s Best Tool!

bondale Apr2 A discussion happened recently on a LinkedIn group attempting to identify the best project management tools. While there was healthy debate, nearly all of the responses pertained to the virtues of different software solutions ranging from applications within the Microsoft Office suite up to multi-million dollar project portfolio management solutions.

However, I was surprised to see that no one chose to honor one of the most powerful, versatile and cost-effective tools in a project manager’s belt, Post-it Notes!

Before you think I’ve gone off the deep end, let me provide my own version of Cyrano de Bergerac’s nose monologue by listing multiple ways in which Post-it Notes can help us better manage our projects.

With Scope Management, they provide an easy method of supporting requirements elicitation as well as scope inclusion and exclusion discussions. Post-it Notes can also be used to facilitate a bottom-up work breakdown structure process by having team members provide activities and then using affinity grouping to work up to key work packages.

With Time Management, they can help you develop an activity network diagram – it’s a lot easier to move notes around on a whiteboard than it is to fix incorrect dependencies using paper and pencil, and this “old school” method can encourage teams to focus exclusively on activity sequencing without becoming distracted by dates or resources as might happen when using software schedulers.

For Cost Management, when estimating costs, they can be used to help team members in brainstorming one-time and ongoing costs. They can also provide critical assistance of reminding team members to complete time sheets or to submit invoices in a timely fashion when stuck on people’s monitors!

Post-it Notes can support inspection activities when we consider Quality Management. After all, who hasn’t used Post-it Notes to mark pages in hardcopy documents which need further review or refinement? They can also be used to label and identify physical components requiring re-work.

If a process map is being developed to identify efficiency or effectiveness improvements, they can be used to develop the right process sequence and to distinguish value-add, non-value-add and value-enabling activities. They can also support prevention activities – a Post-it Note next to a lever, gauge or button can often provide a more timely reminder on correct procedure than a detailed checklist. Finally, Post-it Notes and a whiteboard make it easy to create a quick Ishikawa “fishbone” diagram when trying to identify the root cause of defects or when troubleshooting an issue.

When performing Human Resource Management, Post-it Notes can help the project team to develop a project RACI matrix in a collaborative, iterative fashion and could also be used to construct a project’s organization chart.

They can be used during team building activities – a simple one is for team members to write their names on one Post-it Note, and then have them write something unique about themselves on another. The project manager gathers and randomly sticks these two different groups of Post-it Notes on either side of a whiteboard. Then, each team member can take turns drawing links between the names & the attributes.

When faced with a conflict, project managers could consider having team members individually write what they believe the problem is on Post-it Notes and then have the whole team analyze the perceptions to develop a shared understanding of the true issue.

A project manager can also use Post-it Notes to recognize team members for small wins (getting a “You Rock!” note on your monitor can be a small, but powerful motivator) and helping them to focus on what’s critical by having them write down their top three project priorities and sticking that in a frequently observed location.

The most obvious use of Post-it Notes for supporting Communications Management is the ubiquitous “Come see me when you are back at your desk!” notification. Unlike e-mail messages or phone messages, if the recipient returns to their desk they can’t truthfully say that they never received the message!

Colored Post-it Notes can also be used to differentiate types of work items or the criticality of issues on Kanban boards, Issue boards or other types of visual dashboards. Finally, they can also be used to facilitate identification and grouping of similar lessons when conducting a lessons (to be) learned session with the project team.

Beyond their use in helping a team to brainstorm risks during identification workshops, they can also help when analyzing risks visually – a two-by-two table can be drawn on a whiteboard, and individual risks can be organized by probability and impact across the cells of the table. This is a great way to surface risk biases amongst team members and stakeholders and can also help to focus response efforts on meaningful risks.

When reviewing contracts or Statements of Work as part of project procurement activities, Post-it Notes can be used to flag specific terms and conditions requiring rework or can be used to easily identify where approvers need to sign.

Finally, with stakeholder management, similar to their use during risk analysis, Post-it Notes can help a team to categorize stakeholders on Influence/Impact axis when performing stakeholder analysis.

How many software solutions do you know which can claim to effectively support so many PMBOK knowledge areas?

I encourage you to provide me with more creative uses to support my belief that while there is no panacea tool for project management , Post-it Notes come pretty close!

Don’t forget to leave your comments below.

Project Success is in the Eye of the Beholder

Written by Kiron Bondale on March 12, 2014. Posted in Articles. 3 Comments on Project Success is in the Eye of the Beholder

bondale March12 A common method of evaluating the performance of a project team is to determine if they met approved scope, time and cost baselines. While PMI and other project management advocates have spent significant effort in elevating the perspective of project managers to influence achieving expected business outcomes, most still consider themselves successful if they have met the triple constraint.

Assessing this this would seem to be a relatively straightforward exercise at the end of each project – if the project’s customer has confirmed that approved scope has been delivered, and actual cost and end dates matched the approved budget and timelines, you’d expect that teams should be able to pat themselves on the back for delivering one more successful project.

In a perfect world, projects never experience any changes and there would only ever be one set of baselines. There would be little doubt that delivering originally defined scope on time and on budget could legitimately be considered success.

However, as we know, change is pretty much the only thing we can count on when managing projects.

Some changes are driven by our customers – as their knowledge of what they want evolves to meet their expected outcomes, they will come forward with requests for scope change which after due analysis and approval would usually result in the creation of new cost and time baselines. In such cases, if the project team has successfully been able to deliver to these revised baselines, then they should be happy.

Where things get murky is when changes to project cost or time baselines are not caused by scope changes.

Sometimes, the ability to avoid these impacts is not within the direct control of the project team. Common examples of this include:

Resource reductions resulting from decisions to lower the priority of a project.
Budget reductions due to fiscal tightening measures on the part of the project sponsor.
Schedule changes resulting from cross-project re-prioritization.

In such cases, it would not be fair to hold the project team accountable to their original baselines as no amount of good planning or risk management could have prevented these impacts. Formal project change control should be executed and new baselines established. Then, if the delivery team is able to achieve the new baselines, all should be well.

But how do we handle the scenario of being over budget, behind schedule, or delivering less scope than expected as a result of inadequate planning, underestimation, optimistic resourcing or ineffective risk management. Such cases should be treated as variances and if they cannot be resolved by the end of the project, then the project team should be held accountable for a miss.

However, when we are managing projects for internal partners, you rarely find strict adherence to this “by the book” approach.

Common reasons for not doing so include:

Projects which fall behind schedule or run over budget usually do so fairly early in their lifetime, and if the expected remaining duration of the project is long, there is a strong desire to avoid unnecessarily punishing the project manager and their team members by showing their project as being “red” for a prolonged period of time. The demotivating effects of this negative reporting are likely to impact team morale and productivity hence further hurting the project.
As the project manager is usually reporting up into a senior delivery executive, there is motivation on the part of that executive to demonstrate that their department is meeting expectations.
Schedule delays usually cause increased resource utilization, and if the company’s funding authorization policies dictate that incremental costs have to be managed through formal project change control, then the only way to get the project team to work beyond approved funding limits is to approve a change request.

So what ends up happening is that the internal sponsor is “encouraged” to approve a project change request which formally incorporates the unavoidable variances within a new set of baselines. While paying more or waiting longer to receive expected scope is bad enough, in some cases, if the funding increases cannot be approved or if project deadlines cannot be pushed back, the only option left might be to reduce scope. Then, if the project team claims that they successfully delivered the project based on the revised baselines, the internal sponsor is unlikely to wholeheartedly agree.

If it is not feasible or reasonable to hold project teams accountable for realizing expected business outcomes and if meeting final baselines hides approved variances, perhaps the better compromise is to treat those projects which were delivered to original baselines plus approved externally-driven changes as successful.

To plagiarize Benjamin Disraeli: ‘There are three types of lies – lies, damn lies, and project success.’

Don’t forget to leave your comments below.

The Project Management “Famous Five”

Written by Kiron Bondale on February 12, 2014. Posted in Articles. 4 Comments on The Project Management “Famous Five”

bondale Feb12 Assuming your organization or department has a published project management methodology, chances are that it specifies that at least a few standard artifacts are created and maintained on every project. These artifacts might be standalone documents, or they might exist as a data set within a project management information system.

One of the most valuable pieces of advice in the Guide to the PMBOK (5th edition) is “Good practice” does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project. As such, competent project managers arm themselves with a toolkit of practices to draw upon, and apply them based on the specific needs of a given project, the maturity of the team and organization, and regulatory or compliance requirements.

For example, on projects possessing a significant degree of requirements uncertainty, using iterative and interactive requirements techniques and artifacts which might help to elicit true needs would be beneficial whereas for those projects in which scope and requirements are very clear, traditional methods of requirements gathering would suffice.

Is there such a thing as a minimal list of project artifacts which should be created and maintained regardless of the size, nature or complexity of a project? The benefits in defining such a list is that it would help to eliminate or at least reduce some of the contention which occurs when a project manager has to justify the need for specific practices with a sponsor or other key stakeholder who views such practices as being unnecessary overhead.

Here are five “must have” project management tools along with rationale for selecting these artifacts and the risks in not using them.

Charter – whether this is a single page document or something closer to a high-level plan, the charter is the one tool which a project manager can wield to demonstrate that their project has been formally authorized and, when it is well written, it will help to align key stakeholders and the team towards the project’s expected outcomes. Without an approved charter, it may be challenging for the project manager to engage the resources required to plan and deliver the scope of the project, and there is a greater likelihood of stakeholder misalignment.

Approved plan – agile fanatics might cringe at the necessity for this, but it goes back to the basic criteria which define a project – it is a temporary endeavor consuming resources to deliver unique outputs which will generate business value. In the absence of documentation which clearly states what will be delivered, by when, how, with what resources and for how much, it is likely that the project will either be cancelled prematurely when funding or time runs out, or branded a failure upon completion if customer expectations have not been set and met. Two critical components of this approved plan are objective project completion and project success criteria – without those, the project may turn into a shuffling zombie from the set of the Walking Dead.

Current forecast – it does no good to have an approved plan if you have no idea as to how you are tracking to it. The forecast will cover the same knowledge areas as defined within the approved plan and should be used as the basis for communicating project status. Without this, stakeholders are left to guess how a project is doing, and it will be difficult to detect negative variance trends in a timely fashion.

RAID log – the unique nature of projects generates uncertainty and this artifact provides a consistent, centralized method for managing that uncertainty. Without it, risks may go unmanaged, issues might not be resolved in a timely manner, actions may linger resulting in schedule and cost impacts and key decisions might be delayed or worse, made without appropriate governance oversight and subsequently reversed. The accuracy, currency and completeness of this artifact provides good insights into the overall discipline and competency of a project manager as it is their ultimate shield. If a project manager is not concerned about self-preservation, how much would you trust them to manage your project?

Closeout report – at a minimum, this formalizes the acceptance of a project’s outputs, identify exceptions and the owners for those, and provides the necessary authority to shut down the project and to release resources. While we have all worked on projects where all concerned want to run away as soon as the work has been completed, the absence of this artifact might result in post-project headaches if expectation gaps have not been addressed.

There is an elegant symmetry to this list – the charter and closeout report bookend the project, the approved plan and current forecast are ideally identical twins, and the RAID log acts as the main monitor and control tool.

Have I missed any artifacts which you feel are mandatory? Do you feel any of these Famous Five are unnecessary?

Don’t forget to leave your comments below.