In my previous post for project managers working on mainframe upgrade projects, I recommended that you have your vendor (IBM, Mainline Information Systems, etc.) provide you with a list of your current mainframe configuration and the proposed mainframe configuration so you can:

• Review the current and the new configurations for accuracy
• Question any apparent discrepancies
• See what features are being “carried forward” to the new mainframe and verify that they should be carried forward and that the required quantities are correct
• See what features are not being “carried forward” and verify that this is part of the plan, not an omission
• See what new features have been added (i.e., features on the proposed mainframe that are not part of the current mainframe)

The next step I suggest is to check on (or review again) possible price changes for your software.  IBM or Mainline can provide you with an estimate of your IBM software charges on the new machine.  This is done using a tool called the Workload Pricer (WLP).

The best approach is to have your vendor pull the latest software inventory for your machine and input the data into WLP.  Then, your vendor will model that software against your current machine.  The results should match what you are paying today.  It’s important to get this step right, because you are creating a baseline against which to compare other options.

Once the baseline is right, then the vendor can add a new machine to the model and tell WLP to estimate software costs on that machine.  (You can also model various hardware alternatives that way, too, which probably has already been done during the marketing phase).

Three key things to keep in mind:

1. You will have some products that carry a monthly license charge (usually called “mlc” products).
2. You may have some products that have a one time charge (OTC) plus an annual subscription and service charge (S&S).
3. You may have third party products that will also be affected by an upgrade.

The WLP model will estimate your IBM MLC and OTC/S&S charges for the new mainframe.  It will not estimate third party prices; you will need to contact those vendors directly.

From a PM standpoint, you mainly want to know that you have a complete list of the software products running on the machine and that potential price changes have been explored.

One of the great things about an IBM mainframe upgrade is the “technology dividend” which basically says that a new machine of comparable power will have lower maintenance and software costs than the machine it is replacing.  Combined with a year’s warranty on the new machine, these dollar savings go a long way toward financially justifying the purchase of the most current technology.

Quick recap – at this point:

• You know all of the hardware features on your current and proposed machines and you’ve reviewed them for accuracy
• You know all of the software running on your current machine, along with price estimates for how the upgrade may increase or decrease your software costs

The key is risk mitigation – avoid any surprises.

Don Appleby has served since 2004 as an adjunct assistant professor at the University of Alabama at Birmingham where he teaches in the Information Engineering and Management Program. He has over three decades of professional experience in the information technology industry. Prof. Appleby is retired from IBM.Thanks to ProfAppleby.com for this article.

We are all aware of the Project Management Institute’s five process groups; initiating planning, executing, monitoring and controlling, and closing. Did you know that Agile Project Management has five process groups as well? According to Jim Highsmith it does; envision, speculate, explore, adapt, and close. The first thing that you will notice about Highsmith’s list is the flavor of the words. They have the feeling of an adventurer about to setoff on a new and exciting journey. The traditional project management list seems almost clinical in a way. By comparing and contrasting each process group we can gain further insight into the inner workings of each methodology.

Initiating vs. Envision – When we initiate in traditional project management we immediately begin work down a known path. There is a set set of steps that we follow every time. True to the flavor of agile with envisioning we are brainstorming with our customers about what they want us to build. The output of the initiating phase is a project charter and the output of the envision phase is a vision statement.

Planning vs. Speculate – Similar to initiating, with planning, we have a known set of steps to create a project plan. While the subject matter we are planning changes from project to project with traditional project management we typically use the same tools and techniques. For instance we start with a work breakdown structure, create an activity list, and then create our schedule. With agile we speculate on a possible approach to implementing the projects vision. In agile’s planning phase we create feature cards and hold a time boxed meeting before the start of every sprint to prioritize them.

Executing vs. Explore – In a traditionally managed project when we get to the executing phase our scope, budget, and schedule are all set and baselined. From day to day we track precisely against the project schedule, calculating earned value along the way. In agile we work with the overall vision and our set of feature cards to complete a sprint. The actual activities for the sprint are set, however the order has yet to be determined. We measure progress back calculating a daily burn down and project velocity.

Monitor and Control vs. Adapt – When we monitor and control, we are looking to preserve our original baseline at all cost. Traditional project management expects the plan to be perfect and that we can predict everything we need to do before we get started working on it. Agile on the other hand plans for change and realizes that sometimes we have to adapt in order to preserve the project. For instance, if at the end of that sprint the solution either doesn’t work or doesn’t meet the customer’s needs we start over. While this delay could impact the overall project schedule, thus violating the “iron triangle”, you always have the option to reduce scope later on.

Closing vs. close – Nothing new here, agile projects share most of the same characteristics as traditional projects when it comes to project closeout. The primary difference at this stage of the game is the name of the lessons learned meeting, agile calls it a retrospective.

Brian Rabon is a contributing writer for the IEM Blog. Mr. Rabon is an Adjunct Instructor and the newsletter editor for the IEM Program at the University of Alabama at Birmingham. Mr. Rabon teaches EE606 :Technical Project Management as well as EE 615: Business Process Modeling to clients of the IEM Program. Thanks to http://blog.yourpmpartner.com for this article.