I need to report something about a Banner 9 project. Who do I call?

The Banner 9 project is a big, complex beast with many moving parts. In formal project management lingo, we call it a “program” made up of many “projects.” Some of the work we are doing is for the “program” – like setting up the Dev, Test, and Prod versions. (See earlier post to learn what Dev/Test/Prod means.) That work supports all of the individual projects. However, each project has a unique timeline, a team of staff, and work to be completed. Issues and questions may be related to the full program or directly to one of the projects.

3 circles inside each other. The smallest is labeled Project, the medium is labeled Program, and the largest is labeled Porfolio

With an undertaking of this size, it is inevitable that questions and problems will arise. Instead of asking you to keep all of this straight, the Support Desk (513.529.7900 or ITHelp@MiamiOH.edu) is always a correct method to get attention to an issue. It is the most actively monitored support vector, and is used by all of IT Services.

If you are working with an IT development team on an active implementation, feel free to work out an effective method with the team, but the Support Desk is always a good option.

Dev, Test, Prod – Oh, My!!

So if you are in meetings with software developers or other technical folks you might have heard the terms “Dev, Test, Prod” thrown around. What do they mean and why should it matter?

Following best practices, when IT technicians stand up a new service or make significant changes to an existing service in the data center, they create three separate versions of that service. Sometimes you will hear the term “instances” to refer to those versions. Why three?

The first, Dev, means development. As the name implies this is where the application is shaped to meet Miami’s needs. It is where risks are taken and ideas are tried out. Because the Dev instance uses a clone of the database that will be used when it goes live, developers can see how each change they make impacts the application. (While that data is a mirror of what the application will use, the clone is a snapshot and is not updated.) Once those developers are satisfied that they have a product that is solid, the Dev version is copied to the Test instance.

Again, the Test instance is just what it says. This is the place where anyone with proper permissions can work with the software, using cloned data like Dev, to make sure everything works as expected. While IT staff may be able to do some testing, it is critical for the people who will be using the application regularly to engage in the testing. Does it work the way they expect? Does the output meet their needs? Basically, does it provide the deliverables identified at the beginning of the project?

Once testing is complete and all parties are happy with how the application is working, it is time to move into Prod or production. The last gate a service or application must clear before moving to Prod is approved is called Change Control. A small group of engineers/technicians with deep knowledge of the data center ecosystem review each proposed change to systems in Prod. They look to be sure all potential conflicts have been identified and dealt with in Dev or Test. They check to see that proper communication to end users and support staff is being planned. Only after these gatekeepers provide their approval is the new service introduced to the live, production environment.

This is the big moment. The software is going to be on our live systems and servers. Many systems and applications live together in a shared ecosystem. A problem with one may cause issues for others.  Any problems at this point can be just annoying or could be catastrophic. This risk is why the Dev, Test, Prod processes are critical. If they have been followed rigorously, potential problems have already been addressed and the move to Prod will be seamless.

Each Banner 9 module will traverse these three basic milestones, providing ample room for experimentation, testing, and carefully monitored “go live” plans. So, when you hear the terms Dev, Test, or Prod, now you will know what they mean and where the work is in the process.

Update: 7/17

These Banner 9 modules have been created in Test

  • General
  • Advancement
  • Student
  • Banner Document Management System (resolving issues)
  • Accounts Receivable (in progress)

Production environment hardware installation should be complete today – 7/14. Software prep will begin next week.

Current activities:
  • Installed Advancement, BDMS, General, Student (baseline) modules
  • Testing/Training consultant starts on Monday, 7/17
  • Go Live scheduled for week of 9/11/2017

Financial Aid

  • Interviewing consultant now – start date around August 1
  • Go Live in either October or November
  • Mod re-engineering
  • Initial results look positive

4 mods have been or are in the process of being worked on

Developers are testing an application builder that may significantly reduce the time required to build some mods/standalone forms

Ethos Workflow evaluation and Integration Hub work continue

Scheduling conference calls with Ellucian Subject Matter Experts for each area to discuss mods vs baseline, new features in Banner 9 we could take advantage of, etc

Fun Banner Facts

Did you know that Miami processed over 13 million transactions through Banner last year??

Miami maintains over 800 interfaces between Banner and the university’s other transactional and reporting systems.


Fun With Forms

Last week we talked about fun with mods – this week the project core team is looking at Oracle standalone forms we use in Banner. 126 of these forms have been identified and Jeff Toaddy is playing Sherlock, sleuthing out all the relevant information needed to make decisions about the future of each form. Jeff has had a series of Watson’s – partners from the client offices – helping him understand which clues are useful and which are just red herrings.

To date, 69 forms have been labeled “retire” – that’s nearly 55%. Ten will be rebuilt or replaced, three are part of a mod that has already been evaluated, and the rest are still in “investigation mode.” Watch for more Fun with Forms updates!!

Fun with Mods

At Miami we have 99 “mods” or modifications to Banner. In conversation with other Banner schools, we have learned that our mod count is really very modest. A number of schools we talked to have thousands of mods!

Wading through the mods and forms

Over the past 18 years, we have generated lots of ways to make Banner give us the information we want in the format we want. Some of those have been created via Banner mods (modifications – see Glossary) and some via Oracle forms. Because Banner 9 is so different, we need to be sure any needed mods or forms will work the way we expect – and that may mean rewriting.

The project team tackled the mods first – business office team members leading the discussions. Here is what we found:

Keep: Will Require Project Resources Keep: No Update Needed  Other Retire Totals
Advancement 0 2 0 0 2
Financial Aid  1 2 0 2 5
Finance 2 2 0 1 5
General 1 28 1 6 16
HR 7 4 1 6 18
Student 12 13 1 14 40
Bursar 4 7 0 2 13
Grand Total 27 38 3 31 99

Currently, the teams are looking at the 130 plus Oracle forms that will need attention. Like the mods, the approach will be first to determine who owns or uses the form, is it still needed, and, if needed, what is the estimated cost of rewriting. Watch for more info on Banner forms soon!

Banner 9 Update: 4/10/17


  • Business analysts and client subject matter experts are in the final stages of reviewing mods to determine the appropriate disposition: retire, rewrite, keep with no change.
  • Preparing a presentation of the mods recommendations for the IT governance group, the CCIC (Continuous Improvement and Change Committee). This group owns the final decisions regarding the direction each mod will take
  • Began scheduling process for Mods Review with Ellucian


  • Received a statement of work (SOW) from a potential vendor (SIG) for Extension Training.


  • Received and applied feedback from committee and staff feedback on Charter


  • Continued breakdown of high-level timelines
  • Continued work on draft Communication Plan
  • Interviewed Application Architect candidates
  • Placed Action Item Log on Google for all team members to review/update

Plan for the Journey: March 27

Program manager, Frank Pahlke, was onsite the week of 3/27 and the core team focused on lots of project logistics. Here are some of the highlights:

  • Presented draft project charter to the Implementation Committee at its regular meeting.
  • Continued to plan training on the Ellucian Extension tool for IT Services developers.
  • High-level project timeline being broken down into more granular plans.
  • Mods are being reviewed by staff who use them and by IT developers. Each will be rated by its future state: retire, keep as is, or keep but rewrite. The core team is engaging Ellucian to review all mods that are to be kept to ensure plans align with best practices.
  • The project core team moved to their new project space in Boyd Hall.