The Presentation Tightrope

by: stacey - December 30th, 2011   Filed under: Presentation Add Comment

At its best, a formal presentation is a useful communications tool in the business world. At its worst, it’s a key time to learn embarrassing facts about your coworkers, namely, who snores when they sleep.  A wrongly-seated presentation can be damaging to the communications process if you do not have credibility with your audience, or at least knowledge of them. Without sufficient information about the interests of the audience, a powerpoint presentation often says “this is the information I want you to hear” instead of “this is the information you need”. If you’re off-base on what they want, you’ve wasted your presentation and damaged your credibility as well.

Before going for a formal presentation, work on relationships first. Try to meet and know, or at least know about, all of the key players that you are presenting to. Don’t forget the ‘secondary’ players either. It is very seldom that anyone on the client side is invited to a presentation by accident. Usually, these folks are trusted advisors. Being armed with some knowledge of these people will help you build a better presentation.

If you cannot manage to meet and start a relationship of credibility with the audience beforehand, try to find someone with whom you have credibility who also has a relationship with the audience and ask that person to lead the meeting. Their introduction and testimonial will help to establish some level of credibility for you. If the audience trusts your meeting leader, and she establishes that she trusts you, then in turn you have gained an opportunity to be trusted as well. It’s just like meeting a new circle of friends when you go to a party with a friend- if you’re good enough for their friend who brought you, then you have a foot in the door.

Some of this information here is elementary, but nevertheless it’s important and should never be forgotten. Credibility is easy to build if you know how, but it is also amazingly easy to destroy, and once destroyed, nearly impossible to rebuild.

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: , ,

Pitfalls in Analyzing Resources

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

One of the biggest jeopardies to any project’s timeline is for resources to not be available when you need them. Ironically enough, this seems to be one of the least talked-about risks to project failure. While I have never seen a project totally fail as a result of resource scarcity, I have seen project after project derail because of it. The cause of resource scarcity usually traces back to one thing- failure to understand the resource’s availability.

Here’s an example: a project is dependent on getting a large, complex oracle database set up. The project manager checks with IT and yes, there is an oracle DBA on staff. Yes, the DBA can be available for the project. Yes, the DBA should be available around the target deadline.

Sounds fine, right? What can go wrong here? The project manager neglected to check on a few things, namely:

1) Are there any other projects going on that require an oracle dba? Are any of them higher priority than mine? (Hint: if you’re #3 on the list of oracle dba needers, you should keep a close eye on the other projects and probably talk to the other PMs).

2) Just how many oracle DBAs does IT have? How many of them are actually qualified to do the work you need? (Hint: if they have only one or two, be concerned and include contingencies in your plan)

3) If there’s only one or two DBAs available, talk directly to those DBAs as soon as possible. You need good communication with them from now on. If they are out sick, are planning a two-week vacation, etc, then you need to keep this in the plan.

4) How many production oracle systems does IT have up? Are any of the DBAs IT has offered you responsible for production support? If so, you may be at the mercy of any of these existing systems if they go down, their scheduled maintenance schedules (find out about these!) and change requests for any and all systems that are higher on the company’s priority list than you are. You might even consider checking the bug list for any production systems a lot higher on the priority list than you are, so that you can anticipate if there’s changes coming that may affect your schedule.

Does this example give you a good picture of my point? If you are going to depend on a resource, make sure you check on:

1) The availability of the resource
2) The commitment of the resource
3) The *possible and potential* commitment of the resource
4) The *potential availability* of the resource
5) Where your project falls on the priority list against other potential demands for commitment and availability of the resources your project depends on

To sum it up, there is always a large number of important things going on in any company. Any resource you depend on more than likely is committed to some of these other things. Understand what surprises can come up that can claim your resource, keep up with and plan for these possibilities in your project plans. This will help you build a smarter, more effective timeline.

Tags: