Every Complaint is an Opportunity

I heard this tonight on a commercial for Nationwide Insurance – “Every Complaint is an Opportunity.”  They said they are unique because they will listen to a complaint and try to do something about it.  I have a DVR, so I don’t watch many commercials at all, but I let the commercials play on the recorded show I was watching while I retrieved something from my office nearby and I heard this line.

The Unhappy Customer

That concept really struck me.  It’s sort of like Lessons Learned from a project standpoint.  I’ve always liked to approach my customer relations like this – every comment is important and any negative feedback means there’s something that needs to change to make this customer happy.

It may be that they’re not receiving the proper information, or it’s not timely enough for their liking or needs.  Or they feel that decisions are being made without their input or approval.  Or they’re not pleased with the performance or availability of a resource on the project.  Or maybe they’re just not happy with how the PM is handling tasks.  At any rate, they’re not happy and they’re complaining to someone. 

Take it Seriously

Those complaints can’t be taken lightly, even if you feel they are unjustified.  Each complaint is an opportunity to draw yourself closer to the customer.  An opportunity to fix a problem, fill a need, right a wrong, or ease a stress.  It may be nothing, but acting quickly and aggressively and letting the customer know that whatever it is that concerns them concerns you too is critical.  It’s critical for three key reasons:

• It lets your customer know their concerns are your concerns
• Your customer knows they are being heard and problems will be addressed
• As the PM in charge, you have begun to mend your reputation with the customer which has already been damaged to some degree just because there is a complaint – even if that complaint isn’t with the PM’s performance or even concerning something within the PM’s control

Document, Document, and Document

Be sure to also document all complaints and issues that are brought up by the customer.  Treat them just as you would any other issue on the project – put it on the on-going issues list, track it, discuss it during the weekly status calls and follow it till it’s resolved.  Your customer will be pleased that their issues and complaints have high visibility and are being addressed promptly.  In many of the companies I’ve done work for those weekly formal status reports are visible to everyone on up to the CEO so the customer will understand that their concerns are getting the highest visibility and attention possible.

Summary

Your customer is everything…and without them there is no project.  Treat their concerns, complaints and issues with the highest priority and attention – even if you feel there is no real issue.  Make them aware through some visible tracking method and ongoing discussions that the issue is being addressed.  Just knowing they are being heard and addressed will make customer satisfaction rise significantly and will likely lessen the frequency of future complaints.  Unsatisfied customers find more things to complain about.  Satisfied customers work with you to resolve issues before raising complaints to higher levels in the organization.

How I Became a Project Manager

I thought this might be an interesting topic to write about.  Really…how many of us said that we wanted to be Project Managers when we grew up?  I was going to be a baseball player, then a racecar driver, then a lawyer and when I first entered college – a pharmacist, believe it or not.  I switched to the MIS track and came out of college as an application developer.

The Beginning

My first 3 or 4 years were spent coding in COBOL and writing proposals for long-term government contracts.  After one of those contract wins, I took the role of Configuration Manager on the project.  I’m really dating myself here, but in the early 1990’s I switched to Project/Program Management when I was offered a key position on one of the contracts we were performing on with the US Department of Education.

Couldn’t Code Forever

I recognized early on that I wasn’t truly interested in coding forever.  I needed the interaction with the customer and to lead projects and oversee tasks from beginning to end from a higher viewpoint.  I jumped at the chance to become the Configuration Manager on the Guaranteed Student Loan project we had just won.  I managed all change control for the project including leading the formal Change Control Board and managing a small staff.  Switching to the Project Management path came a couple of years later but was still more like Program Management than Project Management because it was really overseeing on-going activity on a five-year government contract, not running multiple engagements from beginning to end like I think of more traditional project management roles.

My first taste of performing the type of project management that I perform now came in 1998 when I went to work for Rockwell Collins handling their internal internet, intranet and extranet projects and leading a small team of web developers on these efforts.  I thoroughly enjoyed the challenge of overseeing those projects from beginning to end – even handling the ‘sales’ side on these internal projects and sometimes managing up to 10-15 live projects at a time.

Except for a stint as a Corporate Applications Development Manager for a large gaming/hospitality entity here in Las Vegas, I’ve pretty much stayed in the project management track handling usually 4-6 projects at a time.  I like the challenge, I love the customer handling and interaction, as well as the oversight responsibilities for the delivery team.  I’ve found my niche…I’ve found what drives me.  When I need a taste of innovation, I’ve been able to get that from consulting work with smaller organizations helping them either organize their PM practices, incorporate new or better practices, fix problems they are having with customers and solutions and in some cases just help them figure out a better way to do business.  These activities don’t really follow a PM path so they tend to feed the entrepreneurial spirit in me.

Early Mentor

My real career turn from developer toward project manager came from my early mentor/manager who discussed my career path at great lengths with me on many occasions.  From my answers could tell that I was aligning more with a project management interest.  He helped guide me in that direction and helped me to find roles on proposals and other projects that would get me the experience and the foot-in-the-door situation to be able to move into those types of roles.

Your Feedback

That’s my story in a nutshell.  I welcome any questions you might have and I’d also like to hear how some of you became project managers.  I still haven’t had any of my kids say they want to be a project manager when they grow up so I know it’s a discipline you really just ‘happen into’ more than choose, for the most part.  Go ahead…send me your stories.

Dollar Store Concept of Project Management

We’re all familiar with stores like the Dollar Store, 99 Cents Store, etc., right?  At least here in the US, they’re all over the place.  You can walk into any one of these stores, grab 12 items and know for sure you’re going to pay $12 + tax.  No surprises.  Power steering fluid…$1, socks…$1, wine glass…$1, pregnancy test…$1 (though I’m not sure I’d trust it).  Everything they carry costs exactly the same…one price fits all.  Everything is weighted the same and has equal importance to the store’s bottomline.

Equal Importance?

What if that same concept could be applied to IT shops and to Project Management?  Would tech support be just as important and application development.  What about operations, system architecture, performance tuning.  From a project management standpoint, should requirements definition be just as important as design?  Should design be just as important as development?  Should development be just as important as testing?  If you placed a dollar value on each, would they be the same?  Do they take the same amount of effort?

Usually, on an IT project, development takes longer than design….however there is often a higher dollar resource or amount associated with design.  Requirements analysis and definition is an upfront task that requires specific focus and, I think we can all agree, if not done properly can result in many problems later on in the engagement included significant re-design and significant development re-work.

Likewise, testing is an extremely critical portion of any engagement.  You can spend thousands of hours developing a solution, but if it is not tested properly by the delivery team and then by the customer, the likelihood of a successful deployment is almost non-existent. 

Assigning Value

I guess what I’m trying to say here, in terms of a successfully run project, development – while it is actually the act of creating the solution – probably needs less oversight than other phases.  If the others are done properly, then development should be straight forward.  A couple of dev shops I work with often give a rough estimate on a project at 30% design and 70% development and testing, but the per hour estimate for design is higher.  Likewise, requirements analysis – possibly the most important part of any project – must have the appropriate hours and effort and skill level applied to it or problems will occur repeatedly throughout the engagement.  If a project is started and it is later realized that not enough effort was put into requirements definition, it is far better to shelve the project for a period of time and spend additional effort on requirements definition.  I wish I had done that on the project I wrote about in The Worst Project I Ever Managed.

Moving away from project phases and onto project management tasks…is everything weighted the same?  All items are important – all tasks that are regularly performed by the PM are ingredients for a successful project.  But are they all equally important?  As a PM, if you were stretched so thin that you could only perform a few key tasks for a project, what would you do?  For me, I’d delegate as much as possible and focus on one formal status meeting or conference call per week, one project status report (including issues/risks) delivery per week, one delivery team call per week, and one budget/forecast update per week.  Other things like adhoc communication, delivery of documents, etc. would have to be left to project team members and reviewed during status review calls.

Summary

In my opinion, not all IT and PM tasks and functions are equal.  They aren’t all really assigned the same dollar value.  When push comes to shove, there are certain tasks that need more emphasis, greater focus and – when done right – provide a higher likelihood of project success.

The Future of Project Management

It’s 2009…do you know what Project Management is doing for your company?  What will PM look like in 2010, 2015, 2020?  I’m not trying to write another ‘1984’ here, but what will it be like?  Will everyone have to have PMP certification to even send in an application?  Will every organization have a PMO?  Or will none of them have a PMO?  Let’s see what we can predict for the not too distant future in a few hundred words…

Certification

PMI is a great organization and PMP certification gives a stamp of approval to a PM who has acquired educational credits, led projects for the required number of hours and passed a test.  But it doesn’t measure your skills in actually running a project and your success in customer satisfaction, etc.

It is my belief – and you can bash me if you want – that hiring companies place too much emphasis on this certification.  I have nearly 18 years of PM experience, yet no PMP certification.  I was going to get it around 2004 as it was part of a hiring agreement that I would get a $10k bonus upon obtaining certification.  That bonus was important to me, but the PMP certification really wasn’t as I was very busy and preparing for the test was not something I felt I could spend my time on right then.  But, for the bonus, I was going to do it, of course.  Then the company closed down and so did my motivation to get the certification.

I’m probably biased because I don’t have the certification, but I think too much emphasis is placed on it by hiring companies…I think it  trendy to put it in the job requirements.  In the next 5-10 years, I think a push for this type of certification will only increase, not decrease.  That said, if there are any of you hiring managers and CIOs out there who need a very experienced PM and don’t care about the paper certificate, you know how to contact me.

PMOs

Will PMOs be the norm in 5-10 years?  Will they be necessary?  I think so.  A well-run, well-organized, well-stocked, and well-documented PMO can definitely help an organization as long as that organization is large enough to need a PMO.  Smaller IT shops running mostly internal projects can probably just get by with a few project managers and some documented processes.  And these PMs would need to be stationed within each business unit, not a centralized unit.

However, if the organization is large enough with enough project activity going on, then a centralized PMO with a proven leader at the helm is essential.  It helps ensure that someone is fighting for the following:

• PM training for PMO resources
• Common, repeatable processes and documentation
• Project prioritization (project portfolio review)
• Project resource assignments

These are essential to ongoing project success in larger companies.  I believe, therefore, that the PMO will see an increase of installations within larger organizations that are experiencing a significant amount of project activity.  The current economy, of course, will play a big role in the growth of PMO activity, so we’ll wait and see how quickly this happens.

Greener PM

I still stand by my stance that remote and paperless project management is and should be the trend of the future.  In running my projects mostly remotely over the past three years I have decreased my own carbon footprint enormously.  I produce almost no paper for my projects relying on electronic documents and communication methods to very successfully manage my projects.  I’m not driving to the office very often so I’m not adding to pollution and wasting resources that way either.  And by not requiring a physical onsite workspace, I’m not taking up space and resources needed by positions that are required to be onsite (HR, accounting, finance, maintenance, etc.).

This won’t work in small organizations where all resources are already in one building.  But with larger organizations, they’re likely already dealing with a very distributed workforce anyway…so remote project management is just another step in that direction.

The Project Management Blame Game

After reading a comment by “Doug” to my Five More Signs You’re Not Cut Out to be a Project Manager, I felt compelled to write this article.  This is an important topic and it covers an issue that I believe all of us have dealt with at one time or another.

Passing the Buck

Doug states that some PMs have a tendency to blame everyone and everything else when things go wrong.  He says, “Too often I see PMs blame others (suppliers, team members, customers) or things outside of the project (the economy, the weather, the exchange rate).  He’s right.  There are people in organizations – not just PMs – that do this all the time.  And there are PMs – the ones in leadership positions on projects – who are pointing the finger constantly at team members and customers, often just to make sure that they still look good when it hits the fan.

First Remove the Plank

In the Bible, Matthew 7:5 says, “first take the plank out of your own eye, and then you will see clearly to remove the speck from your brother’s eye.”  Doug states in his comment that “a good PM looks in the mirror first and is the first to admit I made a mistake.”  I agree with Doug completely.  As the PM, we’re in charge and everyone is looking to us for our leadership.  The PM must be in charge, and must be ready to take charge and certainly must be ready to take responsibility for things that happen on the project.

I’m not stating that a PM should take blanket responsibility for every bad thing that happens during an engagement.  Not at all. Rather an approach of ‘let’s see what we can do to get through this issue together’ is a good course when the problem was obviously caused by something beyond the PM’s control. The PM should not be a martyr taking on all blame no matter who was responsible.  Nobody really likes a martyr who takes the weight of everything on their shoulders, but nobody in their right mind is going to follow a PM who finger points when issues arise. No good comes from it and no problems are really solved by it…all it serves is to divide the team and that is a recipe for disaster.

What to Do

How do you deal with this type of person – this type of leader?  First, personally, don’t become one.  Have you ever found yourself easily pointing the finger at someone else – even privately among your team members?  I have, and I hate myself for it later.  It can also be detrimental to your leadership position with your team members – if they see you as a finger-pointer in the blame game, then they will not be seeing you as the take charge leader you need to be.

And if you find yourself with team members who display this finger-pointing quality, you should take two actions…

• Re-direct the discussion from finger-pointing to aggressive resolution (if you’re not part of the solution, you’re part of the problem)
• Have an offline conversation with the offending individual about the negative aspects of that type of behavior and it’s affect on the rest of the team

If the private discussion doesn’t have the needed affect on the team member, then take it to their manager and ask that they be reassigned and replaced on the team.  Stop the cancer before it spreads to the rest of the team.