Project Management: Having Vision

I was sitting in church this weekend listening to the sermon and our pastor about the visions and goals of our church – one of those things he does every year about this time as summer and vacations end and it’s back to work and school for everyone. He mentioned Proverbs 29:18, “Where there is no vision, the people perish; but he that keeps the law, happy is he.”

Immediately, I thought…wow…that applies so well to everything we do. And yes, corny as I am, it even applies to project management and the way we manage our teams, customers and the engagement as a whole.

The Project Vision

Vision. We must have vision. As I discussed in “Begin with the End in Mind,” we must understand where it is we’re going and how we’re trying to get there so that we may guide the project and the skilled resources that we’ve been charged with so that we can enjoy a successful engagement.

It’s easy in life and when managing a project to get bogged down with the day-to-day activities that we’re trying to stay on top of. Fires confront us on our projects more days than not and tend to throw us our daily, weekly and monthly targets. Those fires can potentially throw us off the course we set for the project in the first place.

Risks become realized, resources get moved from our projects, and our customers change courses on us with a big change order, scope change or major shift of priorities. Stress sets in and, if we’re not grounded in our direction for the project, we can easily get bumped off course.

I’m not saying anything earth-shaking here, I know. We don’t always take enough time to look ahead at where the project is going and keep our thoughts and understanding on what’s important for the engagement, our customer and our organization. And if we fail to do that, think how far off course our team can get - the team that looks to us for guidance, approval and on-going assignment (and motivation).

Summary

It takes a special kind of leader to remain grounded in what’s important and stay the course. You’ve heard the term “fake it till you make it”, I’m sure. That applies here. As project managers, we’re ordained leaders. We may not be great leaders yet…may not even be very good at it at times, but we’re all learning along the way.

We often have to improvise and “fake it till we make it.” The key to this, in my opinion, is one of those characteristics of a PM that I mentioned…stubbornness. If you tend not to let yourself and your decision-making be swayed by the daily occurrences that go on around you…the bumps in the road…then you’ve already won half the battle. Because when you’re stubborn like that, you have a better chance to stay the course on the project and remained focused on the end goal.

We have to adjust mid-course – it nearly always happens – but adjust with that end goal still clearly in mind and then the success of the project overall is still not put in jeopardy. Remember, the customer doesn’t always know what they want and we can’t act on their every whim…we’re the experts and we must guide both our team and our project to the end goal.

Project Management: Back to Basics

We write about a lot of different topics about or relating to project management on this site. Experiences, mistakes, successes, job openings, fascinating books, and informative articles. And, of course, fundamentals.

I’ve shared a lot of stories over the past few months – experiences from my past trying to relate them to sound project management principles…or lack thereof. I believe that every now and then we need to step back from the discussion of experiences and accomplishments and re-focus on good sound fundamental project management. My wife would probably say nothing could be more boring…but since I’m writing and she’s not, it’s my choice what I write about!

How We Get It Done

Whether you’re managing a construction project, an IT project, a landscaping project, an accounting project, a process re-engineering project, a remodeling project, or basically any other kind of project, the basic fundamentals are still the same.

We utilize, in some form, at least all of the following 5 steps – possibly more – to get from project inception to project deployment:

• Statement/Scope of Work
• Define Requirements
• Design/Develop
• Test
• Implement

Statement/Scope of Work – You start with a scope of work (SOW) that represents what someone needs…that could be you, your organization, an internal customer, or an external customer…but it’s contains information that documents a need.

Define Requirements – Once the SOW is fully documented and understood by all parties, then you can define the requirements in detail. This usually requires a thorough understanding of the following:

• How things work now
• How things need to work at the end of the project
• Why the need is there
• How the solution will be used

Other concerns at this point may be risks that one can envision possibly presenting themselves during the course of the project. It’s important to fully analyze those potential risks, document how they can be avoided or mitigated should they arise and keep checking them regularly throughout the project.

Design/Develop – Next we actually design and develop the solution. These sound like IT terms and they are, but they can apply to construction where we design and build. In landscaping one would design and then build, plant, dig, resurface, etc. However you look at it, this is where you go to work and start to create what the SOW and requirements said you would do.

Test – Once the solution is ready, then it’s time to test. In IT, this is truly testing. In construction, this would correspond to inspection. This is where the customer – whoever that may be – runs through the solution and gives approval or sends you back to perform more work.

Implement – Again, for an IT project, we usually call this ‘deployment’ or ‘implementation.’ For construction, it would probably equate to the final walkthrough. No matter what the industry, implementation is the final step – other than support (or warranty work) – for the delivery organization. This is where the planned solution that should meet what’s outlined in the SOW and documented in the requirements definition, is handed over to the customer ready for processing or usage or occupation, etc….depending on the industry.

Summary

I realize that this probably over-simplifies the process a bit, but we’re trying to write not only for the experienced project managers and other delivery team members out there, but also for aspiring and new PMs that may be part of an organization with no mature process wrapped around project management. Everyone started in PM somewhere – and in smaller organizations there may just be one PM with the responsibility of coming up with all the plans, templates and processes on their own and trying to make the practice work. It’s imperative that we periodically break it down to the simple details of what we’re trying to do.

In an article in the not too distant future…possibly in the next week or so, I intend to provide as many PM-related templates as I can find that I have in my possession. If PMs out there are like me, when a need comes up for a particular plan (like a risk management plan, etc.), you end up scouring the internet for a sample to take, modify and make your own. Hopefully, I can help you all with that process by providing what I have and thus giving you one more sample to choose from.

One Case for Twitter – Comcast / Salesforce Case Study

I have now written two articles fully debunking Facebook of having any real project management or business related application. I’ve gone nearly as far with Twitter – only admitting that it’s good for networking and possibly for reaching out for hard-to-find answers when issues on your projects concerning technology or process may arise.

However, I just read the following situation InformationWeek where a Comcast rep was solving subscribers issues by reaching out to them on Twitter. From a pure project management perspective, possibly the best usage would be post-deployment support or possibly lessons learned information, but it’s an interesting read either way….read on…

Frank Eliason, a Comcast Customer-Service Rep, has more than 13,000 followers on Twitter. In the coming weeks, he’s going to help Salesforce.com figure out how to introduce corporate customer-service systems into the world of Twitter.

About a year ago, Eliason and his team of 10 reps, who primarily answered customer e-mails, began to seek out and help customers who were publicly blogging their criticisms and frustrations with Comcast. The team increasingly concentrated on Twitter and its millions of easily searchable microblogs. Eliason’s readiness to help solve Comcast customers’ problems, while calmly ignoring the occasional insults thrown his way, soon made him somewhat of a personality among Twitter regulars. He’s known as @comcastcares.

Then the media came calling, and in recent months, several newspapers, magazines, and television networks have profiled Eliason. His technique is to tentatively approach Twitterers critical of Comcast, rather than offer up advice that wasn’t asked for. “I never thought I’d become famous on three words: Can I help?” Eliason said.

Now Salesforce wants Eliason’s help. It recently announced an add-on for Salesforce CRM that lets companies track and aggregate customer complaints on Twitter. Eliason and his team will be testing the offering, which is scheduled for general availability in the summer. It’s a perfect fit, since Comcast is already a customer of Salesforce CRM’s Internet (a.k.a. “cloud”)-based software services.

CRM for Twitter will include a dashboard for tracking and monitoring topics on Twitter, the replies to those topics, and whether customer issues were resolved, and it will alert customer-service reps to volume spikes on certain topics. The app will be integrated with Salesforce’s Knowledge Base, which reps use to look up answers to customers’ questions and problems.

Pricing will start at $995 a month for five agents and support for 250 customers. This isn’t Salesforce’s first social networking attempt: In January, it announced an app service that companies can set up to have customers come to them on Facebook (the searchable Twitter approach wouldn’t work with Facebook, since users’ “walls,” where they would post comments, operate on an invitation-only basis). Still, using a team of salaried employees to seek out disgruntled customers on the Web may seem counterintuitive to the typical big-business approach to customers service; that is, stock a phone bank with as many low-cost workers as possible that follow scripts in a database.

But Salesforce executives said during a recent InformationWeek briefing that maybe that’s not the best approach. Perhaps, they suggested, companies need to move beyond the call-center mentality and start reaching people at the place they’re increasingly going to complain about things and get help from others: the Internet.

Twitter, of course, is used by just a small fraction of Comcast’s customers, and Eliason’s team is a tiny speck in a pool of 30,000 customer reps at the company. Still, Eliason said his team has helped solved about 21,000 customer issues on Twitter, Facebook, forums, blogs, and other social networking sites since starting the work a year ago, and he envisions a day when perhaps thousands of Comcast reps can use the CRM for Twitter application.

“This allows us to be much more efficient because it’s going to tie into Knowledge Base,” Eliason said. “My team is the guinea pigs.”

There’s also a big-brother quality to a software service that helps companies find what their customers are saying about them and then intervene. Eliason said it’s all in the approach.

“My advice to companies considering this is that you don’t try to interfere with a conversation,” Eliason said. “If someone is commenting about Comcast, we may not give the answer right off the bat. We don’t force ourselves into a conversation. Instead, we throw the ball in their court, with, ‘Can I help?’ ”

Twitter has also proven to be an “early warning system,” Eliason said; customers will tweet about a Comcast problem before calling customer service.

In some situations, Eliason’s team has known about issues before a Comcast call center. Last year, Comcast reps working on the East Coast at 7 a.m. saw a few late-night tweets about a network problem in San Francisco (4 a.m.). The call centers serving San Francisco didn’t start getting calls about the issue until three hours later, when most Comcast customers in the area were waking up and trying to sign on.

Based on his experience with Twitter, Eliason believes that public social networks will prove to be far more important to businesses than they may are expecting. “Engaging with customers is what works, not PR or marketing or customer-relationship ‘management,’ ” he said. “People respect a company when it’s not about the message, it’s about the personal relationship.”

This article was written by Mary Hayes Weier for InformationWeek. It did not appear in their print publication but was available to subscribers online through an alert download at www.informationweek.com/alert/socialnetworks.

When the Customer Doesn’t Know What They Want

Often times the customer knows exactly what they want and they know what technology they want it developed in and they know when they want it and exactly how they’re going to use it.  These are the projects that usually come with well-defined business processes mapped out (both as-is and to-be) and a solid list of documented high-level requirements…possibly even detailed requirements. 

These projects are the least likely to have scope creep, stand the best chance of avoiding unknown risks and issues and in the long run are the least likely to experience a high level of customer dissatisfaction, unless something goes terribly wrong.

When the Customer is Clueless

What happens on the other side of the coin?  Surely we’ve all had some projects – or at least one – where a project came to you with a customer who knew they needed something, but they really didn’t know what.  I know this has happened to me.  It seems to be most prevalent on smaller projects and – for me at least – internal projects. 

When the customer heads into an engagement with a poorly defined vision of what they want and what their processes are, the risks can be high.  A few to consider are:

• Extreme scope creep
• Longer than anticipate Exploration phase
• Design and Development phases may be lengthened do to changing requirements
• High potential for customer frustration as they perceive that their needs are not being met by the ‘experts’

At this point, because the customer is coming in fairly unaware, it is up to the Project Manager and the delivery team to ask the right questions, drag the ‘real need’ out of them, and help them to form it into a vision of the to-be processes and application. 

When the Customer Seems to Know Too Much

Likewise, we have to be aware of those customers who seem to know what they want, but they aren’t sure why they want that.  Experienced PMs, Business Analysts and developers must remain aware of these types of customers and ask the right questions to truly identify the need. 

If we go down the path and develop a system for a customer who wants something but doesn’t fully understand what and why, then we’re going to end up with a frustrated and dissatisfied customer when we implement a system to their specifications but it doesn’t really fit the need that they themselves didn’t fully understand at the start of the project.  Yes, we will have developed what they asked for on paper, but we won’t have a satisfied or repeat customer.

The Solution

The key for the PM and the delivery team is to not go into the project with blinders on.  Look for these types of customers and be ready to recognize these issues, as they’re not always obvious. 

And for both types, the solution is really the same.  Be sure to:

• Spend enough time during Exploration on helping the customer define business processes and requirements
• Review the SOW and ensure that all deliverables are documented
• Re-work the project plan and re-set customer expectations because Exploration and possibly future phases of the project will likely take longer
• Prepare the customer for change orders due to extended timelines and more effort hours if the original budget has already been set by Sales
• Educate the customer to use their SMEs to help define what they need and why they needed – their end user base acceptance of the solution will be higher

We just have to realize that whatever is on paper is not always the true picture.  It’s never wrong to ask tough questions and ensure that we’re creating something for our customer that they will truly use and benefit from.

The Art of Negotiation – Part 1

Is negotiation part of the Project Manager’s role?  It certainly is.  In fact, without realizing it, the act of negotiating things on a project probably infiltrates just about every role occupied on a project…but it’s certainly most prevalent in the Project Manager role.

Reasons for Negotiation

Let’s take a look at reasons the need to negotiate may arise on an IT project.

• Out of scope work that needs to be included in current timeline
• Customer request for a different resource or skill set
• Customer training
• Budget issue vs. Timeline issue
• Functionality needed earlier than expected
• Data management issues and who handles them

The list can go on and on..these are just a few of the ones that I’ve personally run into on my projects.  The issues usually fall into three different categories:  Scope, Timeline, or Budget.  All of those topics above, when looked at in detail, can be slotted into one of these three categories.  For this article, let’s look closer at Scope Negotiations and how best to handle them with your customer.

Scope Negotiations

We all know that scope issues can abound on any given project – especially if some loose ends weren’t properly tied up during the sales process.  Again, my plug for inserting the Project Manager into at least a portion of the sales process.  When I worked at Rockwell Collins in the late 90’s and early 2000’s and all the projects were internal projects for internal business units – I WAS the sales process.  As was the case with all the PMs at RC, I handled meeting with the customer, documenting the business need, pricing the engagement and finalizing with the customer – and then presenting the proposed solution to a technology council for approval.  Sorry…enough plugging for the PM role in sales…for now.

Back to reality.  It will always happen that there will be scope issues.  When the customer says, “but I thought that was included”, you have to look at it from their side as well as your own.  Do some investigation.  Maybe Sales told them it was included.  Maybe the line was a little grey.  Or maybe you can see some bigger work that is coming down the line on the project in terms of scope and now is the time to negotiate.

At any rate, it’s about the give and take.  For most scope issues you’ll draw up a change order, identify the budget and timeline hits, and present the customer with what it is going to cost to add the additional scope.  If they balk, there may be some room for negotiation – for example, price the implementation of the new functionality but throw the training in for free.  Of course, you may need senior management approval for this – another form of negotiation, possibly.  Explain the need for customer satisfaction, retention and referral or possibly your vision for some bigger add-on work that you can see in the offing.

Another issue that can lead to major scope concerns and the need to negotiate is the lack of previously defined customer business processes or poorly defined customer requirements.  As the Exploration Phase gets underway, this issue really can come to light – if it hasn’t already.  As the PM, this is when I look for the opportunity to negotiate with the customer in terms of creating additional revenue for the delivery organization in the form of a change order. 

It’s obvious at this point of the project that (for example) a two week Exploration Phase is not going to cover everything that is needed.  Explain to the customer that in order to properly document the requirements and create a meaningful Business Requirements Document (BRD), Functional Design Document (FDD) and ultimately a Technical Design Document (TDD), then more time and effort needs to be dedicated to Exploration resulting in additional hours and $$ in the form of a change order. 

Explain that the increased effort added up front helping the customer define their business processes and requirements will result in a more solid solution being deployed to the customer at the end of the project.  It shouldn’t be too hard of a ‘sell’.

Summary

I’m not sure any of us really thought we’d be negotiators when we entered into the PM field.  But it seems to come up regularly on projects.   We’ve examined Scope Negotiations in detail here.  In the next article on this subject, I’ll discuss Timeline and Budget Negotiations and look at examples of each and how to deal with those both with your customers and within your own organization.