Project Management in these Economic Times

We’re living in some of the worst economic times in 60-70 years.  Businesses are closing.  Analysts are estimating a possible 20% vacancy rate for businesses across the country by the end of 2009.  Here in Las Vegas the once flourishing hotel and casino industry is seeing bankruptcy filings and halted construction projects throughout the valley.

So what does this all mean for Project Managers?  Customers sometimes think of Project Managers as the ‘extra’ expense on an IT project.  If you are a Project Manager, then you know that’s ridiculous.  The value added by even a mediocre Project Manager is undeniable – keeping the status reporting, formal calls and project schedule up-to-date and in front of the key project personnel helps to ensure that the project stays on track.  No one else on the delivery team is going to do that.  But a customer on a limited budget may have other ideas.

Why Do I Need a Project Manager?

I was leading a project last year that involved a difficult customer on a limited budget who did not value Project Management highly at all.  The customer-side director-level sponsor was a self-professed Project Manager hater.  When I was assigned the project and made aware of this fact by the PMO Director, my first thought was definitely not “Thank You!”

This was an approximately 6 month long project and I fought very hard for the first couple of months to show value and win them over.  I found that the key to acceptance was to show them value and understanding, strong decision-making, and as minimal an impact on the project budget as possible.  A couple of incidents arose on the project where I was able to step in and get some higher-level technical assistance where normally the project would have floundered without a strong Project Manager, and then I was considered “ok”.  He still hated all other Project Managers, just not me anymore.

Why Buy the Cow…?

Many customers, though, think they can get all of the PM expertise they need from a knowledgeable Business Analyst.  On a very small project, that may be true.  But on a larger-sized engagement, the BA will be too consumed to deal with the administrative processes and the decision-making that would usually be handled by the Project Manager.

To really ensure that an engagement stays on track and that the diverse mix of very talented individuals remains focused on the end goal and moving forward in a straight line, you must have an experienced Project Manager steering the ship.  There’s no one better to coordinate the communication, manage the budget, produce the status reports and lead the status meetings.  Bottom line, if you want your IT engagement to run as smooth as possible, it is imperative that you pay for the Project Management effort.

Conclusion

IT leaders are smart.  Customers are ultimately smart, too.  Even in these troubled economic times when companies are cutting workforces in record numbers, Project Managers still will remain key resources on initiatives.  The bigger concern for PMs is that there are and will continue to be fewer of these engagements taking place.  Companies are maintaining and reducing, not undertaking new work.  Fewer new projects are starting so the overall need for Project Managers is dwindling just as it is for resources across the board.  Project Managers must dig in, keep themselves current and relevant, and maintain strong connections within their organization and continue to show value on each and every engagement they lead.

KMO in the BPO space

BPO has been one of the fastest growing sectors in the Indian industry for while now, and with the increasing number of companies trying to capitalize on this area existing players are finding that they’re margins are being squeezed. Boosting margins and not loosing business as a result of high costs are right at the top of any corporates “To-do list “, one way of accomplishing this is to use low skilled individuals at a low cost to boost margins. The biggest disadvantage of this as every knows is the that the quality of the work suffers a great deal which could very easily lead to loosing clients.

So how do you increase your profit margins and still keep quality high? The most logical way would be to improve the efficiency and the effectiveness of your agents on the floor and Knowledge Management provides a method of doing just that.

Having scoured the web for information around the benefits of implementing a KM tool within a BPO organization the points below seem to stand out the most.

Efficiency

• Decreasing average handle time
• Minimizing talk time

Effectiveness

• Increasing first call resolution
• Decreasing call escalation percentages
• Reducing repeat calls
• Reducing agent training time
• Provide consistent, accurate answers

Innovation

• Creating opportunities to cross-sell
• Increasing customer satisfaction
• Decrease employee turnover

Knowing which areas to improve performance is the first step to establish a KM framework that could tackle these issues.

The biggest disadvantage BPO’s face is that a large number of them deal with highly confidential client information that is so safely guarded that most processes work as separate entities within the BPO. There isn’t any information sharing outside this area, however capturing ideas like best practices and replicating them across the organization and in every client process would display an immediate improvement, an approach most BPO’s do not follow in a structured manner.

If you’ve implemented KM within a BPO organization do leave a comment here.

Managing Change on an IT Project: Part 3 – Implementing Change

Change on a project is nearly inevitable.  Sales closes a deal with expectations set at ‘x’.  The delivery team goes onsite and starts to work through requirements and into design with a customer and there becomes a realization on either or both sides that there is a gap to some degree between expectations and reality.

So far we’ve discussed the process of Identifying Change and Negotiating Change.  Now we’ll cover the process of Implementing Change.

It Really Was Out of Scope

As the Project Manager, to get to this point you or someone on either side of the fence has identified a potential scope issue and brought it to the attention of everyone involved.  A draft change order identifying the scope change, budget impact, and schedule impact has been created, delivered to the customer, reviewed, discussed, and approved.  Now, the delivery team must implement the change.

Really, the work to be performed happens as all other work on the project.  The difference really is in the fact that the budget needs to be amended and tracked and the schedule likely needs to be amended and tracked.  This new budget and schedule is what you’ll work from at this point and going forward.  I will highlight the fact one more time that before any work on the change starts, be absolutely certain that the customer has formally approved the change order and given approval for the work to begin.  Otherwise, it can be very costly for the project, the delivery organization, and damaging to the relationship with the customer.  Nothing should proceed without the proper approval 

Document Updates

Requirements approval has already basically happened with signoff on the change order.  However, the Business Requirements Document (BRD) should be updated (if applicable), the Functional Design Document (FDD) should be updated (if applicable), and the Technical Design Document (TDD) should also be updated, if applicable.  Because the BRD and FDD are usually formal deliverables to the customer, the customer sponsor should review the changes and signoff on these documents again.

Testing/UAT

If the solution is already in production, then the remaining process is not much different from the regular tasks that go into any IT implementation.  Following the revision of the BRD and FDD, development work can begin.  Once that is completed, the developer and relevant individuals on the delivery team will perform a system test to ensure that everything is working properly and according to the revised FDD.  Once the system test has been successfully completed, the customer should be engaged to perform User Acceptance Testing (UAT) on the modifications and a quick UAT on the system as a whole.  It is very important that when pricing the change order, the Project Manager includes time and effort for these critical activities.

However, if the system is still in the Design, Development, or Testing phases when the change is identified, then the only thing that needs to be modified for UAT would be test scripts and test cases to ensure that the change is properly tested by the customer.

Implementation

No matter when the changes are made (either pre-deployment or post-deployment), following a successful UAT, the changes can be moved to production.  The change has been formally documented in the change order and signed off by the customer.  The change has been tested as part of the overall UAT or a separate UAT depending on when the change was identified.  As previously mentioned, always ensure that the customer signs off on a successful UAT and system go-live so that the line has been drawn in the sand for any future scope issues and change order work.

Managing change through a downturn

Redundancies mean smaller organizations, and smaller organizations require different ways of working.  If you lose some of the Accounts team, who will process the invoices?  The credit crunch is hitting businesses in different ways, and one of the impacts on project managers is being involved in projects to sort out some of these issues.

“Ideally, you’d like to right-size the organization based on what’s required by the way work gets done; however, I haven’t noticed that there is any conscious alignment right now between right process and right size,” says Jonathan Gilbert, PMP, director of client solutions for ESI International.  There has been a rush to cut costs by cutting staff, and while project managers seem to be faring relatively well when heads are lost, we are still impacted by organizational changes.  “The economic downturn has resulted in a current shift in organisational focus away from implementing long-term changes, such as process improvements, and toward the quick hits created by the current spate of organizational downsizing,” adds Gilbert.

There is also the issue of where to spend the available capital.  There’s less money available for new projects and programmes, so companies have to prioritise what to spend time, effort and therefore money on.  And it’s even more important that any changes they do invest in ‘stick.’  There is no point delivering change for those changes – of any kind – to  not ‘take’ within the business.

“Trust needs to be the underlying environment in any change initiative,” advises Gilbert.   “Currently, there is a paucity of trust in organizations, as organizational members question the need for downsizing, and organisation leaders wonder how hard everyone is really working.  My experience tells me that when times get tough, leaders tend to deal with the massive disequilibrium of tough times by micro-managing, which breeds even more distrust.”

As project managers we can contribute to fostering trust within our project teams by following Gilbert’s three steps for successful change initiatives:

• Identify the necessary change, communicating directly the intent and direction that the change implores
• Engage the workforce in aligning around the intent and direction of the change, thereby creating an environment that allows people to have their own insights about the need for change, and the necessary direction and intent of the change
• Implement the change in a way that allows the people who have to live with the change a chance to execute the prototype solutions for enacting the change.

Essentially, involving people every step of the way without micro-managing them will increase your chances of the change being accepted and therefore becoming the new status quo.

If that all sounds quite complicated to implement, focus instead on building your proficiency as a professional project manager and agent of change.  Gilbert’s four top skills for improving your abilities to manage change successfully are:

• Deep listening:  the ability to hear and empathise with the people being impacted by the change
• Emotional intelligence:  a facility to understand the physiological, neurological and emotional responses that we all have to change in our lives
• Questioning:  the ability to ask questions that allow people to have their own insights about what the change really means (as a leader, you cannot tell people what insights they should have – they have to arrive at them on their own)
• Patience:  an ability to suspend urgency for a time while people work through their responses to change because everyone will adapt to change at different rates.

The good news is that all these skills are things you can work on without the need to attend expensive training courses or seminars!  So there is no excuse for not building your skills, even during a period when your company may be cutting back on training.  As a starting point, how about reading The Change Management Life Cycle: How to Involve Your People to Ensure Success at Every Stage which you can download here.

Lessons Learned

How many times have we all wished we could take a mulligan, to borrow the popular golfing term – on an action or decision we made on a project? I know I have on more than one occasion. The goal is to always learn from our mistakes so that we aren’t destined to repeat them. There are certain issues that arose on past projects that I will never forget and would do things differently in the future to ensure they didn’t happen again. But what about others? How can others benefit from issues that we encountered? That’s where the formalized concept of documenting ‘Lessons Learned’ comes in to play.

I discussed this to some degree in the methodology article Project Phase 8 – Post-Deployment. A good Project Manager should be documenting potential Lessons Learned throughout the project, but at the very least many things that are included throughout the engagement on the issues and risks lists will eventually be discussed during a more formal Lessons Learned review.

Benefits

As previously discussed, there are three main benefits specific to the project and the project team members of going through a formal Lessons Learned review process. These are:

• Provide the delivery team with good feedback and useful info for future engagements
• Document project-specific issues that may be relevant to tech support after hand-off
• Increase customer satisfaction and provide the customer with useful project information as they move into the post-implementation support mode

One additional, long-term benefit that can greatly help future project teams and customers is documenting the Lessons Learned and making the formal documentation available on a company Sharepoint or Wiki-type knowledge database library.

The Review Process

Following Project Phase 7 – Deployment, and during Phase 8 Post-Deployment, reconnect with the customer to go through one or more formal meetings to discuss the issues Lessons Learned. This activity is led by the Project Manager and should include all project team members on both the delivery team side and the customer team side.

Below are two links to examples of documents that can be used to aid in the Lessons Learned process. The first link is a Microsoft template that outlines questions that need to be answered during the Lessons Learned formal review process. Out of these questions will come the formal list of Lessons Learned and the likely proper course of action that should have been taken in hindsight. The second link is to a Lessons Learned checklist from the State of Vermont site. This more or less helps identify whether or not all the bases were covered during the engagement.

The links:

• MS template – Lessons Learned documentation process
• State of Vermont – Lessons Learned checklist

I think they’re both useful, but I tend to use something more like the MS template in conjunction with the project issues and risks lists to come up with an overall list of Lessons Learned for the project which identifies impact, outcome, how it may be mitigated in the future, etc.

Once the project moves into the Post-Deployment phase, it’s a good idea to bring Tech Support up to speed on the issues from the project and a good way to do that is with the Lessons Learned documentation. Sharing Lessons Learned in a central knowledge database like a Sharepoint or Wiki database is a great idea and can help ensure that future projects use corrective action early enough to avoid the pitfalls that occurred on your project.