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:

Sweat the Small Stuff

by: stacey - December 21st, 2011   Filed under: Project Management Add Comment

In project management, it is often the commonplace that trips us up.

People overlook easy things when faced with challenges. Some do it because they fear the difficult task, and thus their focus is on it and not the simple tasks before them. Some relish the challenge of the difficult. Those folks will overlook the simple stuff just the same.

Tough and difficult tasks in your projects will usually be done well- at least, to the best that your staff is capable of. They will bring their ‘A’ game, think, and pay attention. The tough tasks will draw attention and praise if done well. You don’t have to sweat these things- if your staff can do them, they will. Just put the right people on it and give it the right amount of attention.

The small things, on the other hand, can kill you. People assigned to the tough jobs will often slop their way through the easy tasks to get them out of the way. They’ll guess wildly at estimates, do the work too quickly, forget basic details and costs. Don’t let this happen to you. Sweat these details. Get the small work doublechecked, including the estimates. If possible, keep as much of the small work away from the people doing the heavy lifting on your project- not to help them do the hard work better, but to insure that the small work it done well.

Remember, a car will fail faster if you forget to tighten the lug nuts as it will if you don’t get the compression ratio of the engine just right. Always sweat the little things.

Tags: