How Much Did That Discussion Cost?

by: stacey - January 10th, 2012   Filed under: Management, Planning, Project Management Add Comment

There’s a cool little tool called Meeting Miser that has been making the blogging rounds.  I first saw it on Download Squad, then Lifehacker, then Raven’s Brain, and they all raised good points about it as a fun little tool.

I love this tool and have used this concept for years.  Not just as a fun tool, but as a very serious tool.  Meetings seem like a way of life in some companies, and you can easily spend tons of time in them, but you always have to ask yourself the cost, especially if you are holding those meetings to solicit information to help you make decisions.

I was once involved with a series of meetings that centered around studying and deciding whether or not to make a business decision that was going to cost our company around $10,000.  That’s not a small investment and worth talking about.  Still, after a few weeks it was out of hand.  We were including too many people and agonizing over the decision too much.  I brought the problem to the attention of my boss (the ultimate decision-maker).  The conversation was something like this:

“Hey, we’re spending a lot of time on this.”

“I know, I need to make a decision, we need to think a bit more about it I think.”

“Well, think fast, you’ve spent $5,000 on this decision already.”

That got his instant attention.  It was a rude jolt, to be sure, but it was a needed one, and well-received.  He asked what I was talking about.  I pointed out the number of hours in meetings, pointed to the average cost per person’s time that we use for pricing project resources for the people in those meetings, did a simple math calculation, and poof.  $5,000, give or take a few hundred.  That ended the meetings right there.  He made the call the next day based on the information he had.

Being cautious and risk-averse is a reasonable approach to doing business, but never be so cautious you overrun your costs just trying to make a decision.  Keep your meeting costs in mind.  Calculate the estimated cost of a meeting BEFORE you call the meeting, then decide if what you’ll be accomplishing in that meeting is worth the cost.

Tags: , ,

Who Comes First?

by: stacey - January 3rd, 2012   Filed under: Leadership, Planning, Project Management Add Comment

A Project Manager’s job is to get their project done.  On time and within budget.  Period.

Right?

This is a trend I’ve seen in many places.  The project manager fights for their project to a fault.  They get the money and resources they need.  They win the battle of conflicting priorities for shared resources.  They take no prisoners and get things done.  While in the process of doing it, though, sometimes they rob other projects and processes of resources, and that ultimately hurts the company significantly.

As a project manager, you can never lose sight of the fact that you work for the company, not the project.  When there is a scheduling conflict, you have to ask questions and find out what the conflict is and what the importance of the other item is to the company.  There are ultimately times when you should stand down and let the other people through.

Your stakeholders can sometimes make this a delicate balancing act.  They will not always agree that the other project should be let through.  Not everyone thinks in terms of the Company as a whole.  You should take the time to explain yourself, though, and if you find yourself and what you believe is the correct thing to do in conflict with your stakeholders or, worse, project sponsor, take the time to escalate.  Don’t do it in a contrary manner; simply consult the right authority in the company and ask which choice takes priority.  Once you do that, report your findings and acquiesce to it.  Refer to the higher decision and seek help from leadership in explaining things if necessary.

Doing the right thing for the company is not always good for your project, but ultimately it is the right thing to do for your career. Demonstrating to leadership that you can think globally about the company will ultimately help your career.

Tags: , ,

Are You Ready to Upgrade?

by: stacey - December 29th, 2011   Filed under: Planning, Product Management, Project Management Add Comment

Most of us who have ever been involved in implementing a piece of enterprise software has faced this. You gather requirements and evaluate software vendors. You jump various political hurdles inside your company. You build your implementation team and start ramping up to install the product. In this middle of all of this, blammo! The vendor changes upgrades their product. Sometimes the upgrade is no big deal; sometimes it’s radical- like they rewrote it as a web application, or the app that used to be in powerbuilder is not written in c# or java. No big deal because you planned for that to happen, right? Uh, right?

For most companies, the answer is wrong. When evaluating vendors, never forget to do some basic homework on their future roadmap, how it will affect your project, and how their roadmap matches up to your plan.

Here’s some things to do to prepare for major version changes during your implementation:

1) Managing the version change within your project plan and scope
If there is a version change or other major product upgrade in their roadmap, be sure that you put that in your project plan. Make sure that you put time in your project plan to evaluate the new product and adjust the project plan according to the requirements of the new product. You doubtlessly will have to upgrade to the new version to achieve support from the vendor at some point; it’s easier to change now than after you’ve gone to production with the product. Treat this essentially as a major change request would be treated, only you have the bonus that you know when it will (probably) be and can schedule this in your project. If you are tempted to put it off until after you go live, don’t. This is like all other major project changes. The later it happens in your project, the more money and resources it will take to implement.

2) Managing the version change and having the right resources
Do you have the right resources available for the new version? If the code base changes in the new version, you’ll need programmers and techies versed in that code base. You’ll need systems architects available when you evaluate the new version of the product so that you can determine if the new version requires more and/or different hardware. You will probably need a business analyst to look at the new features in the next version to consider how the way the product will be used by the company may change and improve. You may need testing folks to change their testing plans, if any are already written, and you will likely need your trainers to adjust any material they’ve done up to now.

3) Managing your resources before the version change
Do not make the mistake of doing work for the sake of having people work before the change in versions come down. There will be a lot of work that can be done beforehand. There will be some work that may become obselete with the new version as well. Evaluate your task list carefully. Don’t waste time sitting around waiting for the new version, but don’t waste resources working on things that will be rendered obselete either. It’s a careful tightrope to walk.

Last but not least, never forget to document, document, document. Keep up with your vendor’s version upgrade schedule. You will have to upgrade the product again after it is in production. This is a learning experience as to how to do that. Save as much lessons learned and project plan material as possible from your upgrade so that you can make your future transitions more smooth.

Vendor products change. This is a reality of their business model. Plan for the change so it can fit within your business model.

Tags: , ,