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.

Lessons Learned; Avoid the Oxymoron

Written by Kiron D. Bondale

We’ve all been there – you’ve just completed a significant project, you assemble the remaining members of the project team (those that are still sane), the sponsor (if one exists) and the other stakeholders (those that still like you) and you conduct a post-project review. You dutifully ask each participant to think back over the lifetime of the project (which sometimes feels like the lifetime of the participant) to elicit any useful information that could be applied to future similar projects. You capture these lessons “to be learned” in a document and archive the document (similar to the Ark of the Covenant in the first Indiana Jones movie) knowing that it will never be seen by human eyes again.

So what went wrong? Here are just a few of the challenges with the traditional approaches to lessons learned:

• Conducting an effective “lessons learned” session at the end of the project requires that participants have photographic memories or have logged “candidate” lessons throughout the project lifetime in preparation for closeout. Both are unlikely, so only a superficial collection of lessons is possible.
• Document-centric approaches to capturing lessons discourages project teams from searching or reviewing this valuable information when planning projects. Even if the lessons learned documents are stored in a centralized document management system, the manual effort of opening and reviewing individual documents is a barrier to their use.
• Lessons are in many ways like risk events – if they are too general, too stale, or non-actionable, then their value (and credibility in the lessons learned process) is lost.

So what can you do to improve this situation?

• Make it extremely easy for people to submit lessons learned and incent them to submit them over the lifetime of the project. Perhaps you can spare 5-10 minutes at every second project status meeting to capture these lessons.
• Take a data-centric approach to lessons learned instead of a document-centric one – setup a simple online process to capture or search for lessons as individual items. Make sure that submitted lessons can be tagged with such useful information as the project description, the date of the lesson, the person that submitted it, and key words to locate them.
• Institute a regular scrubbing process to weed out obsolete or irrelevant lessons from the lessons repository and to add clarification or key words for the valid or useful ones.
• Add a “usefulness” flag to the lessons items (similar to the “Did you find this solution useful?” query that most product support organizations use on their online support sites) to identify the lessons that have been the most valuable and to help weed out the ones that are not that useful.

Like any other improvement initiative, applying these recommendations will take time, but as George Santayana said, “Those who cannot remember the past are condemned to repeat it.” I invite your feedback and you can reach me at kbondale@solutionq.com This e-mail address is being protected from spambots. You need JavaScript enabled to view it . Our website is (http://www.solutionq.com).

Article first appeared in www.projecttimes.com/blogs

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. (http://www.solutionq.com) 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 been a presenter for multiple conferences and webinars.