Skip to main content

Author: Kiron Bondale

Old Projects Never Die; They Just Fade Away

Written by Kiron Bondale on . Posted in Articles. 7 Comments on Old Projects Never Die; They Just Fade Away

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. For more of Kiron’s thoughts on change management, please visit his blog at http://kbondale.wordpress.com.

Project Administration – Sure Beats Root Canal Surgery!

Written by Kiron Bondale on . Posted in Articles. 8 Comments on Project Administration – Sure Beats Root Canal Surgery!

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.

Don’t forget to leave your comments below

Capturing the Hearts and Minds of Project Risk Stakeholders

Written by Kiron Bondale on . Posted in Articles. 5 Comments on Capturing the Hearts and Minds of Project Risk Stakeholders

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

Tips for Identifying the Walking Dead

Written by Kiron Bondale on . Posted in Articles. 5 Comments on Tips for Identifying the Walking Dead

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 impartial project 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!

Your Project has been Targeted for Termination – Now What?

Written by Kiron Bondale on . Posted in Articles. 3 Comments on Your Project has been Targeted for Termination – Now What?

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.

I look forward to your comments and you can reach me at [email protected], or through our website (http://www.solutionq.com)