If You Want Happy Customers, Give Them Less Information

by: stacey - December 16th, 2011   Filed under: Communication, Customer Relations, Project Management Add Comment

Guy Kawasaki wrote a great post a while back about customer happiness.  I’ve seen this at work before.  My parents, for example, have been thinking about buying a big screen television for years.  The problem is, nowadays, there’s HDTV, LCDs, DLP, plasma, projection, etc.  The choices are too many, the television makers are not clear on what it all means, the salesmen keep sharing more and more technical details, and so in frustration and confusion they simply do not buy.  If someone simply made the decision about what the television looked like, what size they want, and ‘hey, look how nice this picture is’, they would’ve made the decision by now- but the sales folk don’t do things that way, and so they lose out on the sale.

So it goes in IT and project management as well.  Too many times, we want the business to understand that we’re thinking ahead for them, that we’re using the right technologies, making good decisions, and sometimes the business simply does not care.  It’s not that they don’t want us to make good decisions, its that that’s our job, and they don’t need to hear about it.  They need to know when we’ll make their jobs easier.  The key is understanding when you should simplify things for the client, and when you should not.  Here’s a few example cases.

When the Sponsor/client cares about the end result:

Sometimes, people just want their problem solved.  They don’t care that you’re using web services to solve their problem.  They don’t care about the database.  They don’t care about anything except solving the specific business problem that they’ve identified.  What you should report to them is when you’ll be done, when the documentation and training will be available, and when you think they’ll be able to put the solution to use.  If this is what your client wants, then anything else other than updates to these three pieces of information likely just irritates them.  The result is everything to them.  If you talk about all the details you are wasting their time, and to them you are focusing on the process rather than getting them their result.  Stick to the basics.

When you are late on a project:

See the item before.  No matter how much the client may care about the process and the details when you’re on track, once you’re late, then they can get impatient.  Stick to the details of what you’re doing to get things back on track.  Don’t worry about the rest until you’ve solved that problem.

When your problems are not the client’s problems

The client’s problems consist of the fact that they don’t have their solution yet, what to do until it arrives, all the communication and change management around the solution implementation, training their staff, listening to their staff complain about things changing, learning how to use the new solution, providing training, and dozens of other things not related to your project/product.  The difficulties related to RPMs not compiling correctly on the linux installation are of no interest to them- that’s your problem, and that’s why you’re in charge of the project, not them.  In fact, there’s some chance that they don’t even care if you’re using linux, windows, unix, or bands of mongoose that quickly rewrite their screen every time they click on something new.  They just want their solution, and if you can tell them how you’ll make their other problems easier, that’s an added bonus.

Other times, you should share as much information as possible with the client.  Some examples are:

The solution will be delivered in phases

The client isn’t getting everything they want up front.  This complicates their lives.  Share as much as possible about what they can expect and when.

The client will be maintaining the solution after implementation

If the client has to maintain whatever it is you’re delivering, then you can’t give them enough information.  They will want and should have as much say as possible in as many decisions as possible.

All in all, understanding the right amount of information to share with the customer goes a long way towards their happiness.  Share too much, and you’re wasting their time and your own.  Keep your project reports tuned to the audience’s needs.

Tags: , ,

Why Gantt Charts Are Useless in Agile Development- and How to Make Them Useful

by: stacey - December 13th, 2011   Filed under: Project Management Add Comment

The Tyner Blain blog posted a while back on Why Gantt Charts are useless in Agile Development.  They’re right on many levels- I personally struggled with this early on in working with Agile Development.  I know many PMs do.  Every PM should read this, whether or not they’re working with Agile Development.  It applies just as much in a business environment that adapts and changes to business needs as it does to Agile Development.

At the same time, Gantt Charts *can* be used in Agile Development.  Like in Agile Development itself, it’s all about adaptability.

The key is to learn to build your project plans in a modular way.  Within every project, even an Agile Development project, there are some tasks that simple must depend on one another and must be completed in order to complete a given goal.  To meet a specific business requirement, for example, you know that you need to develop function X, Y, and Z.  You know you must write requirements, you know you must write test plans, you know you must test, you know you must release them.  If you intend to deliver a complete solution for this business requirement within a single release, then that’s your module.  The number of iterations within that module, the order within that module, is not as relevent as the fact that you are going to do all of these tasks, and must do all of these tasks, in order to deliver a solution this business requirement.

So now that you understand something about a project ‘module’, how do you manage with it?  Try these steps:

1.  Develop your project’s task list as normal.

2.  When you create your project plan, organize your task list into modules.  Assign modules to software releases according to your current estimate as to what order that these things will be delivered in.

3.  When your project team, or your management team, shifts, then shift the modules within your project plan.  This WILL sometimes wreak havoc with your plan, particularly levelling and dependencies.  You will learn ways to adjust so that it’s easier (I could give pointers here, but really, I’ve learned that it’s heavily dependent on your style of PMing).

4.  Communicate, communicate, communicate!  You will need to constantly put out updated projections and updated task schedules when doing things this way (Agility does not come without a cost).  Your team must always know what’s coming next, so that the preparation work needed for it can be ready (for example, requirements for the next phase of development must always be ready before the developers finish the current phase).  Your management must always know how the delivery dates change, so that they can manage to the new schedule.

There is more to it than this, but again, it’s heavily dependent on your management style, and so your mileage will vary a bit.  Once you get used to it, it’s extremely effective- think of it as “Planning to not have a plan”.

By planning your modules carefully, and watching your dependencies to always keep the right ground work queued up, you can be ready for anything.  Your team will be ready to change directions on a dime, and be truly Agile.

There’s a saying I heard in a college psychology class that has stuck with me for life- “The most flexible part of a system controls the system.”  In the business world, the most flexible company in a market is capable of controlling the market (just look at Apple and Google).  Planning for Agility is tough- get used to it.  If you can pull it off effectively, you have a massive advantage.

Tags:

Politics of the Back Room and How to Cope

by: stacey - December 12th, 2011   Filed under: Leadership, Project Management Add Comment

Everyone out there in the business world is overly familiar with meetings. You probably have several per week, if not several per day. We hold meetings, in theory, to communicate and to make decisions as a group.  I’m here to tell you that that’s often nonsense.
The fact is, most successful meetings consist of no *real* decisions being made. More likely, decision makers meet over lunch, near the coffee pot in the morning, while on the treadmill at the gym, or some other place outside of the meeting room beforehand. There, they talk over the issues without the trappings of a formal meeting and involving tons of people in the process to dilute the discussion. They make a decision, then spend their prep time before the meeting planning how to use the meeting to bring everyone around to the conclusion that they already made.

This may sound jaded. You may say that things aren’t done that way at your company. You may be right. However, in most places, this is the way things happen. You need to know this for several reasons:

1) Understanding how things work help you function in the political arena of your company.
2) Understanding how things work can help you influence how things happen in your company.
3) If you are having too many meetings where no decisions are made, perhaps you should consider using these tactics yourself. Get the decisions made outside, then leverage the meeting to create agreement.

The third note may sound underhanded and overly political. If you do it well, it isn’t. Talk to everyone on your team individually. Get a feel of what they want. Gather facts from them. Use these facts to answer questions for others. You will find that if you talk to everyone and help them to get a perspective before the meeting happens, everyone will likely have reached a similar conclusion well before the meeting, resulting in a smooth, simple, quick meeting where everyone arrives and reaches quick understanding. If not, they are at least armed with more and better facts to discuss the topic.

Tags: ,