I Come to Bury PMOs, Not to Praise Them

PMOs are frequently portrayed as a panacea for an organization’s project management issues. Evangelists will pontificate that without this organizational construct, the ability to achieve excellence in project portfolio management (PPM) or project management execution is often unreachable. They may also point to the value of a PMO as an efficient means of gathering, normalizing, and communicating project and resource decision support information.

However, PMOs do not come without costs and challenges. PMOs struggle to deliver measurable business value within their first year of existence while at the same time incurring significant costs. These costs might result from consulting services purchased to facilitate the setup of the PMO, the total cost of ownership of tools to support the PMO as well as the recruiting and ongoing internal labor costs for PMO staff. Organization conflicts that can accompany the launch of a PMO can impact productivity and employee morale – if the mandate or authority for the PMO is not well defined and communicated or if there is a shift in authority from functional managers to project managers, a power struggle could occur that reduces perceived value.

Failure rates for PMOs are high (surveys have reported that between 20-25% of PMOs will not survive more than three years) and given the upfront costs and delayed achievement of business value, organizations should be absolutely sure that a PMO is the best way to achieve their PPM or PM-related business objectives. There are alternatives to setting up a PMO to address tactical issues such as project failure – better engagement of stakeholders, true project sponsorship, basic project management training for all staff and having skilled project managers are a few methods of achieving the same desired goal without the need to set up a PMO.

I’ve worked with many clients for whom a PMO was viewed as the “home of project management” – within its walls, project management flourishes and miracles are performed to get troubled projects back on track. However, outside of this utopia, behaviors do not change – governance practices are still afforded only lip-service, resources are still vastly over-allocated and excessively multi-tasked, project sponsors continue to remain invisible and project commitments are made without proper planning or justification.

PMI’s envisioned goal that “Worldwide, organizations will embrace, value, and utilize project management and attribute their success to it” underscores the need for our profession to transcend an artificial construct such as a PMO. I draw an analogy to the evolution of quality in the manufacturing industry – so long as it was viewed as being performed by a quality control or assurance group, it failed organizationally. Only when it becomes a core component of all organization practices does it truly flourish.

Setup a PMO, and you risk establishing a crutch that prevents an organization from truly institutionalizing project management – while PMOs can facilitate improvements within low maturity organizations, I believe that in the not too distant future, successful organizations will look at PMOs as being as obsolete as a mimeograph machine.

Don’t forget to leave your comments below

---

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. (http://www.solutionq.com) which produces and implements project portfolio management (PPM) solutions. Kiron has worked for over twelve years in the project management domain with a focus on technology and change management. He has setup and managed Project Management Offices (PMO) and has provided PPM consulting services to clients across multiple industries. Kiron served as a volunteer director on the Board of the Lakeshore Chapter of the Project Management Institute (PMI) for six years and remains an active member of PMI. Kiron has published articles on PPM and project management in multiple industry journals and has delivered presentations within the PPM/PM domain at multiple conferences and through regular webinars for Solution Q and the PMI Healthcare SIG. For more of Kiron’s views on change management, please visit his blog at http://kbondale.wordpress.com or contact him directly at kbondale @ solutionq.com.

Overcoming Project Management Super Villains

Delivering our profession often requires super-human effort and, as we all know, a super hero is only as good as the super villains they have to defeat.

This article covers three of the super villains that plague project managers and provides some insights into how to deal with them.

1. The Scope Shape Shifter

The scope shape shifter can be identified by frequent changes in requirements and other scope elements. Just when you think you’ve got the shape shifter’s requirements nailed down, they morph into something else resulting in budget overruns and schedule delays. If you try to enforce rigid scope control practices with them, they escalate and complain that you are “nickel and diming” them or are not paying attention to customer satisfaction.

One way to deal with the scope shape shifter is to use an agile project management approach that encourages refinement of requirements over the project’s lifecycle. If you are unable to apply agile practices due to the nature of the project, structure it in a phased approach and focus on delivering the highest priority requirements first, leaving medium or lower priority requirements for future phases (and hence open for change by the customer).

2. The Sponsor from Another Dimension

The extra-dimensional sponsor starts out by being all that you want a sponsor to be -communicating the value of their project to all stakeholders, securing the necessary funding to get the project kicked off, and providing you with a vision of how they see this project benefitting their world.

Unfortunately, the moment you escalate a project issue, or assign them as the owner of a risk event, they have dimension-shifted back to another plane of existence from whence they can observe unscathed the chaos occurring in your world.

The key to keeping these sponsors in our dimension is to engage them only when absolutely necessary and in appropriate “business terms” (so they don’t feel overwhelmed with information that they perceive is of little value to them), to ensure that project success is considered part of their performance evaluation (by appropriately leveraging your influence across the organization), and if all else fails, to have an appropriate escalation path to be able to drag them kicking and screaming back into our world.

3. The Prima Donna

On many projects you may forget that you are the project manager and start to feel more like a babysitter. At least one of your project resources might be extremely reluctant to provide timely progress updates without frequent nagging, may ignore assigned issues, and in general does not “play well” with fellow team members.

To defuse this situation before it occurs, it is very important for project managers to establish expectations for communication and team interaction as early as possible. These expectations should be reinforced on a regular basis during team meetings.

The project manager should also strive to establish good relationships with resource managers, which makes the process of escalating concerns about specific resources easier to deal with. The worst thing a project manager can do is to pander to prima donnas. If their behavior is tolerated, they will go from bad to worse, and other responsible team members will be demoralized.

Have I ignored any of the key arch-villains? Let me know.

Don’t forget to leave your comments below

---

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars. For more of Kiron’s thoughts on change management, please visit his blog at http://kbondale.wordpress.com

Stealth Projects – Why Should We Care?

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.

Don’t forget to leave your comments below

---

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars.

Old Projects Never Die; They Just Fade Away

Written by Kiron D. Bondale   

You thought that this day would never come – the scope of your project has been delivered and you are ready to close out the project. Your team breathes a sigh of relief and looks forward to some well earned time off. Unfortunately, the project closeout phase can sometimes cause more grief than all the other project phases combined.

Here are some tips on how to drain your project swamp before your team becomes mired in closeout quicksand.

1. Avoid closeout criteria confusion. Before you and your customer sign off (formally or informally depending on your project management governance practices) on your project plan, make sure that there is a clear definition of acceptance conditions that should be met for the project to be closed out. Then, re-check those conditions and make sure that you and your customer have the same understanding of them. By working through interpretation gaps about deliverable acceptance practices and other such conditions up front, you reduce the likelihood of these gaps causing prolonged delays and rework during project closeout.
2. Establish (and maintain) good financial relationships. In many organizations, projects cannot be considered closed unless full financial closeout occurs. However, as financial cycles for reporting may not necessarily mesh with your project’s timelines for closure, this could cause a project to be held in an “open” state beyond expected timeframes. This is where a good relationship with your procurement and finance staff as well as your vendors can go a long way towards accelerating timelines – being able to get copied on invoices or to receive summary financial reconciliation reports in a timely fashion is key.
3. Break the walls down. Remember that your project is just a delivery mechanism for achieving business value. To achieve that business value, an operational team will need to execute and support the new or changed business processes delivered by your project. Be sure to prepare for this transition thoroughly. This includes knowledge transfer, transitioning open project issues that are material in the operational world, organizing and archiving project documentation appropriately to facilitate access by the operational team. And be sure to involve key operational stakeholders in the closeout review meeting to ensure that their needs are met and that they are willing and able to grab the relay baton and run with it.
4. Give a hoot, don’t pollute. Projects generate a vast amount of soft and hardcopy documentation over their lifetime. Not all of this information is required once a project has been completed. Take the time to weed through document repositories, project war rooms, file servers and other information stores to archive unneeded files and to properly organize official documents for easy future access.
5. Evaluate your team. Even in functional organizations where project managers have very little power of any kind, there is value in providing written feedback to team members on their performance. It may not get used by their functional managers as an input into performance evaluations but the team members can add it to their own personal portfolios. It also demonstrates that you respect their work and the effort they have made.
6. Harvest the lessons (to be learned). Although this should have been done throughout the lifetime of your project (see my earlier blog article – http://www.projecttimes.com/blogs/69-kiron-bondales-blogs/345-lessons-learned-avoid-the-oxymoron.html), project closeout is your team’s last chance to document useful tips for future projects. In addition, it is an opportunity to scrub or refine lessons that had been documented earlier in the project’s lifecycle.
7. Celebrate. Whether or not you have a formal budget approved for a project closeout event, it is important to take the time to celebrate your project with the team, stakeholders and customer. A good way to prepare for this celebration is to take photos or video clips of significant events over the lifetime of your project. Analogous to the videos that are shown at weddings (or perhaps a better comparison would be at funerals!), this gives everyone the opportunity to reminisce about the good, the bad, and the ugly that they experienced. Further to this, I would recommend burning copies of this video to DVD and presenting the attendees of the celebration with a gift-wrapped copy of the DVD.

When it comes to project closeout, do not follow Dylan Thomas’s advice “Do not go gently into that good night…”

Don’t forget to leave your comments below

---

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars.

Project Administration – Sure Beats Root Canal Surgery!

Written by Kiron D. Bondale

Project administration is as appealing as root canal surgery for most project team members. They are already accountable for completing in scope activities and helping to resolve issues on multiple projects as well as completing their normal operational tasks, so where can they find the time to do this overhead, low value work?

Regardless of the PM methodology used for a given project, project administration exists. On the low end it may be as minimal as reporting which specific work items have been completed and effort remaining on incomplete work items. On the high end it may include time entry, issue, action, task and risk status updating.

Convincing project team members that these activities are a necessary part of their work on your project is a challenge, especially when you have no formal authority over these resources. As project managers, what can we do to alleviate this pain? One approach could be for the project manager to shoulder this burden on behalf of the team, but that is hardly a good solution. The PM will end up with little time to manage all but the smallest projects.

Here are a few ideas that may help to minimize the effort spent by team members on project administration:

• Reduce the need for duplicate data entry: If your organization requires staff to complete a timesheet for payroll purposes, work with your Human Resources department to determine if time data provided by team members across projects can be utilized (or better yet, imported) into the payroll reporting system. If you have multiple stakeholders on a project requiring different levels of project status data, remove the need for team members to have to report on the same work at multiple levels of detail – make them responsible for providing status updates at the task or issue level. You (or if you are lucky enough to have one, a Project Control Officer!) can generate the necessary reports at other levels of detail.
• Strive for a consistent status reporting approach across all the projects worked on by your team: It is very frustrating for a resource to have to learn and complete different formats or types of status reports for different projects. In organizations with a PMO or that use a centralized project information reporting or tracking tool, this procedural consistency may be easy to attain. In organizations without these support mechanisms, consistency is still possible through coordination and communication between project managers.
• Minimize the effort required to complete a status report: A simple status report for a project resource should be able to capture the following information within less than a half an hour of effort per week: updated status of assigned tasks & issues as well as actual time expended (tracked at the highest level required to meet management reporting and schedule and financial control objectives). Leverage technology or standard templates as much as possible.
• Use these status updates as the primary source of information for management reporting: if stakeholders continue to go directly to individual team members in an interrupt or ad hoc fashion to understand what is going on, this defeats the value and rationale for team member-driven status updates.

Assuming you follow these practices, how can you sell your project team members on the benefits of their complying with project administration procedures? Communication messages to help with this change can center on:

• Empowering them to own all information related to their work on a project.
• Putting them back in control of their schedule as opposed to be being interrupted frequently by project stakeholders demanding updates.

While team building during project initiation or planning, set expectations around project status reporting, and actively solicit and attempt to incorporate feedback received from the team into fine-tuning these reporting procedures. This will help to strike a good balance between management reporting and control objectives, and effort expended.

---

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars.

Capturing the Hearts and Minds of Project Risk Stakeholders

Written by Kiron D. Bondale

PMI has recently released the Project Risk Management Standard and while there have been hundreds of articles and books written about project risk management, this standard should help to raise our profession’s overall level of knowledge about this oft-poorly implemented discipline.

It would be ideal if we could convince our project stakeholders to read this document before they get involved with our projects, but that is unlikely. I also assume that you may have struggled on past projects with getting key stakeholders to review risk registers (to say nothing of the challenges you might have had with getting them to appropriately execute risk response plans).

Here are a few (pragmatic) practices that could improve this situation:

• Be careful about inviting external or senior management stakeholders to risk identification and assessment workshops. I know, this sounds counter to the mantra of “wall-to-wall” communication that we strive for. At the same time, most risk identification sessions I’ve attended have a “doom and gloom” or “venting” nature to them – this could turn off an external stakeholder. The high volume of low severity risk events identified and discussed could drown out the impact of the few critical risk events that are raised.
• Focus on doing detailed analysis and developing risk responses for critical risk events – those that cannot be responded to within the project team are excellent candidates. Be ruthless about weeding out the generic or ridiculous risks from the register – all it takes is one poor risk to impact the credibility of the practice.
• Be as specific and detailed as possible with regards to risk descriptions and be extremely clear about the potential impacts. Try as much as possible to quantify the potential impacts in terms of schedule, cost, quality or other tangible metrics that a stakeholder or executive will find meaningful.
• Build the risk response actions right into your project schedule. By having these actions buried within a risk register, it is pretty easy for everyone other than the project manager to ignore them. If they are part of the schedule, it becomes a lot harder for risk response owners to plead ignorance – of course, this requires that the risks are critical and actionable!
• Review the risk register at every second project team meeting (e.g. once every two weeks) and after any significant project change is identified or proposed. Don’t spend hours on this re-assessment, but ensure that the risk register is current otherwise you will again risk impacting future credibility or participation in the practice.

If you are interested in getting a few more ideas that can help move project risk management from theory to practice in your organization, read the PMI Project Risk Management Standard or you can sign up for the Practical Project Risk Management webinar offered by my company at http://www.solutionq.com

Don’t forget to post your comments below

Article first appeared in: http://www.projecttimes.com/blogs.html

---

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has set up and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars.

Tips for Identifying the Walking Dead

Written by Kiron D. Bondale

My last article focused on how project managers can deal with the fall out and other changes brought about as a result of a project termination decision. This might have been perceived as putting the cart before the horse as it assumes that organizations have well defined criteria that are used to decide which projects should be terminated. Unfortunately, most organizations are haunted by the undead corpses of those projects that have survived long past their useful life. A contributing factor to the proliferation of these zombies is the lack of objective criteria as well as inconsistent decision-making regarding project termination.

In this economic climate, the inability to consistently terminate projects is competitive disadvantage as it robs organizations of the ability to focus on high value projects that will help them survive a downturn and come out much stronger on the other side than their competitors.

To improve the consistency of project termination decisions, introduce an impartialproject delivery assurance process that gets executed on all active projects (over a certain size) on a quarterly basis. This delivery assurance process could look for the following tell-tale signs of “rigor mortis”:

1. The project’s business benefits (tangible or not) are not expected until the end of time.
2. The project sponsor never existed, is the Invisible Man, or has entered the Witness Protection Program.
3. Ask the question of your portfolio steering committee or of all Department heads – will you care if this project gets axed. If no one says “yes” or no one can remember the rationale for the project, get it off the books!
4. Ask the question of the sponsor (if you’ve located him/her) – “Would you initiate this project today?” See if they can look you in the eyes when they answer “Yes”…
5. The achievement of the project’s business benefits is heavily tied to external factors or to the successful completion of high risk internal initiatives.
6. (Re)do a risk/reward evaluation of the project (which had hopefully been done prior to the project being approved) – if the project now looks more like a dead dog than a cash cow, you’ve found a winner!

Do you see a trend? None of the questions I’ve asked are using traditional ways of evaluating project health – this does not mean that are ignoring earned value management, the triple constraint and your issue logs, but we simply can’t afford to have successful operations, but dead (or undead) patients.

Given how morbid my last two articles have been, you may wish to read my article on identifying valuable projects (http://kbondale.wordpress.com/2009/06/30/what-makes-a-project-valuable-in-this-economy) – it certainly is more upbeat!

---

Kiron D. Bondale, PMPis the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars. (http://www.solutionq.com)

Your Project has been Targeted for Termination – Now What?

Written by Kiron D. Bondale

Termination of a large active project is like undergoing root canal surgery – intellectually you may realize that you need to have it in order to avoid serious long term impacts but that does not help to reduce the trauma associated with the event. The Kübler-Ross model of how individuals deal with traumatic situations (http://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model) is apropos when understanding the personal impacts of project termination. In the economic rollercoaster of the recent past, we have all likely experienced the fallout of having the plug pulled on a project into which we had invested significant blood, sweat and tears (whether as a project manager or a team member).

While we can acknowledge that the project team and stakeholders are going through these phases, a project manager needs to be able to guide the team through this challenging time in order to close out the project in a professional fashion. With that in mind, how can project termination affect some key project closeout activities?

1. Operational Transition. Unless there were no useful deliverables produced over the project’s lifetime, there is going to be the need to transition products, processes or services to an operational state. The operational owners for these deliverables should have been identified up front during project planning and should be ready to receive these deliverables, but there may be the need to provide training or other knowledge transfer that was likely planned for a future date. There may also be multiple open project issues related to these deliverables that were also planned for future resolution. In both cases, additional activities may need to be completed to ensure that “the baby is not thrown out with the bath water”. The effort, timelines and costs associated with this operational transition need to be estimated and this information needs to be presented to project sponsorship for approval so that the project team can proceed.
2. Contractual Closeout. The decision-making process leading up to project termination should have included an assessment of the costs or penalties associated with the early termination of open contracts. If it did not, this assessment needs to happen ASAP and vendor management or procurement may need to be engaged to assist with supplier negotiations. Once this has been done, termination clauses should be exercised and all open contracts can be closed out allowing the project team to finalize project financials.
3. Resource Evaluation, Recognition and Release. In some cases, resources are freed up from a terminated project to work on a higher priority project. This is the happiest of cases – in the worst of cases, termination in a projectized organization could result in resources being laid off. In both cases, it is crucial that the project manager effectively communicates with all team members, empathizes with affected team members and focuses on motivating the team to complete close out activities. This may require tangible or intangible incentives, pep talks, or one-on-one conversations to help the dissolving team stay on track. While resource evaluation prior to release from projects is a good idea in any circumstance, it is even more important in the case of project termination to help resources with future performance evaluations (or job interviews). Recognition is also important – although it may feel more like a wake than a celebration, there is morale-boosting value in organizing and holding a (modest) get together to recognize individual achievement.
4. Knowledge Capture. “We learn wisdom from failure much more than from success” – Samuel Smiles. In my inaugural blog article (http://www.projecttimes.com/blogs/69-kiron-bondales-blogs/345-lessons-learned-avoid-the-oxymoron.html) I had written about the need to capture lessons learned throughout a project’s lifetime, but if that has not been done, project termination provides a unique opportunity to interview team members and stakeholders when they are most likely to be conscious of what could have been done in a different fashion. While it may seem akin to pouring salt in an open wound, this practice is a good way to ensure that lessons are truly getting learned.

While this is not an exhaustive list, your organization’s project management methodology should include a checklist or guidance that covers the specific activities that need to occur when projects are terminated. This has article focused on the impacts and activities stemming from a project termination decision. The next one will provide a top ten-list of criteria that organizations could consider when trying to identify candidates for project termination.

---

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has set up and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. He has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars.

The Agile Conundrum

Written by Brad Robbins

If you’re like me, you have read and listened to vast sources of information on both predictive project planning methods and Agile techniques.  If you’re in the business we’re in here at Solution Q, you’re even more predisposed to it.  And finally, if you are going or have gone down the Agile route from a more traditional project structure, you’re probably numb and wearing glasses by now.

So yes, there is lots of information out there on this topic.  In many cases, traditionally the content was coming from the perspective of one passionate side of the argument or another.  More and more we see perspectives coming from the middle, speaking about the virtues of both approaches.  And in my opinion this is a good thing as both approaches do have strengths – and like all things in life – compromises.  A good example of this kind of perspective was written by Kathleen Hass on the blending of Traditional and Agile Project Management.

I would like to share our experience and perspectives on the topic of transitioning from traditional to Agile management practices.  Call it the initial results of our own ongoing case study – lumps and all.

We explored the idea of moving to Agile about 18 months ago when we were starting to plan a major new product platform.  At that same time we had a Development Team Lead with some interest in Agile and a desire to lead the charge on his project.  So we started down the road of running this smaller release project using Agile concepts while we were in the very early discovery phases of our larger platform project.

As the “owner” of these projects, I was an interested and very committed participant watching this unfold on two very different projects.  The initial results of our first Agile project were extremely encouraging.  As the project sponsor (or “product owner” in the Agile vernacular) I felt very engaged in the project – both in terms of input as well as visibility into its progress.  I was required to be directly involved at minimum on a weekly basis, which I committed to as part of this project anyway.  But the active engagement and meetings – both formal and informal – naturally lead to much greater participation.  Additionally, we focused very clearly on tasks and features based on priority with an assumed hard release date.  Every sprint – initially 1 month intervals – we had clear goals up front, and clear results at the end.  Now, our results and achievements didn’t always meet our goals, but at least it was all visible, and I never once got surprised.

At the same time, the other much larger, more nebulous project was beginning.  This project was still in its very early days and in fact had a much smaller team initially.  We had defined a fairly broad discovery and R&D phase to allow for some technology decisions to be made, and to get some of the required but less visible “fundamentals” in place.  This sub-project was not managed using Agile practices.  Throughout this initial project we struggled significantly with understanding where we were and when we would be done.  In comparison with the other project that was running in parallel (the Agile project), this one seemed like a black hole.  Clearly Agile must be the difference – or so that was the easiest conclusion to jump to!  And now for the rest of the story…

As we finally finished up our discovery sub-project (traditional) and published our first product release using Agile methods, we re-aligned our teams moving forward.  The majority of our resources moved over to our new platform project and a smaller group stayed on our current technology.  We established a Scrum project (our Agile methodology of choice) and updated our processes and development tools accordingly.  This included implementing a Scrum template, clearly defining some new roles and establishing some ground rules for those roles and the project in general.  We would have a Scrum meeting every day and decided to commit significantly to the Scrum concepts.

A few observations and revelations that came about pretty quickly:

We experienced the usual human divide; some people on the team jumped on board easily and enthusiastically and others struggled with the transition or pushed back.  Everybody eventually got on board. I think the team mentality forged, as part of Agile/Scrum facilitated that.

We gathered some momentum out of the gate.  While change is often difficult for many people, I have also found that it can be just what the doctor ordered to light a fire under smart, capable people who have become a little complacent – and some of us were guilty of that.

As a product owner, I committed to not only being involved in Sprint Planning and Reviews but also attending as many of the daily Scrum sessions as possible.  This was the best decision I could have ever made.  It immediately overcame one of the biggest apprehensions I had which was going an entire sprint (iteration) “blind” and then getting surprised with the progress or lack thereof at the end.

Since much of the discovery and foundation was done in the previous sub-project, the process of defining Product Backlog items (our high-level features and characteristics) and then prioritizing those became extremely valuable.  Regardless of where and what kind of project I work on in my future endeavours I will use this technique as part of my planning processes as it reminds you to think about business value to the customers you are serving, and this is never out of place.

 A couple of other things happened that reminded me a project is still a project, Agile or not.

Even within short sprints, we initially over-estimated how much we could accomplish within a given time-box.  The benefit of short sprints is that you see this quickly and can react in near real-time, but you still don’t accomplish miracles given the same human and financial resources.

We run a business, and businesses require planning outside of your projects. BUT often your projects are key inputs back into management planning.  So while everyone around the management table supported our teams approach and was enthusiastic about the work we were undertaking, we still needed to answer the age old question – when will it be done and what will that include?  Don’t let anyone fool you.  Agile does nothing to answer those questions, posed together, any better than any other methodology.  Nor should you expect it to.  It does however allow you to work towards a deadline (real or self-imposed), and challenges you to constantly prioritize requirements knowing that change is inevitable and scope is your variable.  If you can’t accept a product that is not going to contain certain features or meet certain specifications by your deadline, you have some decisions to make.  Does this sound familiar?

Now before Agile purists let me know that I am not entirely converted, you’re right.  We’re not all the way there and I’m not sure if or when we will be.  I do believe however that our hybrid approach has served us well and gives us some invaluable lessons learned that will help us make the right decisions as we evolve further.

What key things did we learn in retrospect?

First, the initial discovery project was a struggle, NOT because it was using traditional methods as compared to Agile, but because it was by its nature all about overcoming many unknowns and answering many new questions, some of which we couldn’t even anticipate up front.  And more importantly we didn’t have a good scope defined against which to measure in the first place and we let too much time go by without getting some clear visibility on progress and status.  Classic mistakes that can impact any projects success.

Priority, focus and short time-boxed delivery cycles are great practices under any name or in any methodology.  Even if you are planning and running your project using a predictive, waterfall structure, early and constant delivery and feedback increases customer engagement, input and satisfaction.

Finally, your success ultimately comes down to your people.  Specifically, putting the right people on your team in the right roles – or as Jim Collins would say “getting the right people on the bus and then putting them in the right seats”.  This is true because high quality, focused employees and consultants are generally more productive than their lesser counterparts, and they also make better decisions more often when they come to the inevitable forks in the road.  They have a better sense of when to communicate, when to raise flags and identify risks and issues, when to protest bad management decisions or assumptions and when it’s time to just put your head down and “get it done”.  Of course we are more likely to succeed if we were fully stocked with superstars.  What project team wouldn’t?  But Agile practices do NOT rely on you having the best people more than any other methodology – as is often discussed – but it sure reminds you that it is as much about people in the end as it is methodology.

Brad Robbins, Vice President Product and Customer Management. Brad is a founding partner of Solution Q, a Project Portfolio Management (PPM) software solution and professional services company.  He holds a B.P.E from McMaster University in Hamilton, ON.   Brad has spent the past 15 years in the IT services and software industry in a variety of capacities.  With Solution Q, he has been responsible for operations, product development, engagement management and successful implementation of PPM software and services.

Avoiding Potholes on the Road to Earned Value

Written by Kiron Bondale 

You will be hard pressed to find a person that has taken some project management training who has not drunk the purple Kool Aid called Earned Value Management (EVM). You may have run into EVM “evangelists” at project management conferences or symposiums. You can recognize them by that glassy stare that comes from rolling up one too many work package cost calculations and you may have even learned to run for the hills when they have cornered some neophyte who expresses ignorance about the whole concept or (worse) challenges its practical applicability.

All joking aside, with the emphasis placed on EVM’s benefits, you may be inclined (or coerced) to apply it to your next project. To help you avoid some of the more common beginner pitfalls with use of EVM practices, here are three tips:

1. Consistent progress reporting on tasks or work packages is crucial. If you do not set expectations about standards for progress reporting across your project work packages (or even worse, in a portfolio/program situation, across the different projects that you are overseeing), rolled up value calculations will magnify these inconsistencies. Whether you want to be a purist and accept only 0 or 100% (good luck “selling” that in most organizations!) or see the world in a few limited shades of grey (0, 25, 75, 100%), ensure that there is consistent progress reporting to ensure that you can do an “apples to apples” comparison between project, sub-projects, or work packages.
2. Be aware of non-critical paths. If you have team members that are neglecting critical path activities but have completed multiple high value non-critical path activities, you could end up with favorable schedule variance calculations even though you are behind on the critical path. I recall a project where team members spent a significant amount of time on non-critical path work packages and the project manager reported favorable schedule performance far past the point where the end date was in serious jeopardy. This is where you may want to consider doing a separate set of earned value calculations focused on critical path activities or at least do not use schedule variance as the sole metric for evaluating schedule performance.
3. Be aware of cost imbalances between one-time costs (e.g. capital expenditures) and ongoing costs (e.g. labour or consulting fees). Similar to the previous point, if one time costs occur earlier or later than originally planned, cumulative cost data could negatively impact the accuracy of variance calculations. Variances in these one-time costs can also “mask” performance issues. If a computer server is much cheaper than was originally budgeted, the cost savings could hide poor labour productivity or performance on another work package. As much as possible, separate one time costs so that you can get a more accurate performance picture.

Earned Value Management IS a recognized best practice for objectively assessing project cost and schedule performance, but, as Ben Parker would say, “With great power comes great responsibility.”

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. which produces and implements project portfolio management solutions. Kiron has managed multiple mid-to-large-sized IT projects, and has worked for over twelve years in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management consulting services to clients across multiple industries. Kiron is actively involved with the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter from 2003 to 2009. Kiron has published articles on project management in a number of industry publications and has presented PPM/PM topics in multiple conferences and webinars.