The Higher Ed Process Principles of a Successful Project Manager – Part 3

I believe that project management success is about bringing the top people, processes, and technology together to empower organizations to achieve their collective goals.

Guiding principles provide a “dial-tone” for a successful Project Manager (PM). Like that recognizable sound you hear when lifting the telephone to your ear that lets you know it’s working, principles become a familiar “voice of reason” that keeps the manager grounded and focused while working through the difficult project issues.

I shared my “process” principles in part 1, and my “people” principles in part 2. Today, I will be focusing on the “technology” principles as my final update of this series for successful Higher Ed project management.

Most Higher Ed projects have a technology component. However, if the project involves only operational process change or the development of a non-technology product, the same people and process principles still apply. The Project Manager (PM) modifies the process program and organizes the plan with only the non-technical best practices.

If new technology is a factor, plan for adequate time at the beginning of your project for an assessment of the various options. Management needs a clear understanding of the requirements, and must ensure transparency by including the proper operational and IT stakeholders during the evaluation and selection process. Uninformed technology choices can cause PM’s to conduct projects on the wrong note from the very beginning. An assessment sets the stage for selecting the best technology for that institution’s specific requirements, ensuring that the project team remains in harmony until the curtain drops.

The PM also needs to understand where the project’s tech decisions fit within the organization’s reference architecture (technology stack guidelines) to facilitate the best strategic selections—both in the short and long term. If the selection is already understood and approved technology, the PM can remove the assessment steps from the project plan. However, an assessment is strongly recommended for the project if the solution is new or to be built upon “non-preferred” technology. The wrong technology choice while defining the project can sink the ship right after leaving port or at any point during the voyage. Attempts to recover would be similar to rearranging the Titanic’s deck chairs.

Staying true to your people, process, and technology principles from the beginning to the end of your projects, helps you to consistently find ways to address key issues and take projects successfully across the finish line.

7 Technology Principles for Higher Ed Project Management Success Include:

1. The Right People and Processes Help to Select the Best Technology

The role of the PM is to mobilize the best business and IT stakeholders to define the requirements for the use of the technology. If the technology is not already available at the university, the PM facilitates a technology assessment. The key to making the best selection, though, is to have the top people within the organization participate in the assessment and to score each option. In many cases, multiple options can seem attractive.

The people who judge the project’s success must embrace the technology that is chosen. If they don’t and management proceeds, warn about the potentially rocky road ahead, and create a solid change management plan (which allows you to measure the organization’s willingness to accept and eventually adopt the workflow changes created by the new technology).

2. Follow the University’s Reference Enterprise Architecture Standards and Guidelines (If Available)

Reference Enterprise Architecture (EA) Standards and Guidelines define the school’s use of technology. The reference architecture “stack” is the foundation for making smarter technology choices. Schools that standardize the technology stack tend to become more efficient and cost effective, as there are fewer technologies to learn and support. Software and hardware maintenance costs also tend to be lower. The PM’s job is much easier when tech choices are clear and business needs are already being met by the stack. If the reference architecture does not exist, consult with the university’s Technology Lead and/or Chief Architect. Typically, that individual can provide the necessary guidance. If not, recommend recruiting an architect role while staffing your project. Again, the best people will select the appropriate technology. Inadequate personnel, or those without the bandwidth to make an informed decision, can lead to incorrect technology selections that have adverse impacts on the project and university as a whole.

3. Establish Clear Acquire/Integrate vs. Build Decision Criteria and Guidelines with the University

Remember, the business leads IT. There might be legitimate business reasons to change or deviate from the guidelines.

Technology assessments rely upon IT to provide the necessary technological guidelines, while the division or department provides the business requirements. However, IT plays a vital role to ensure the technology that is selected can be supported properly for years to come. Any technology guidelines that are proposed should not be treated as concrete rules. Remember, the business leads IT. There might be legitimate business reasons to change or deviate from the guidelines, but you should be sure that the university is aware of the potential cost implications of deviating from the guidelines, and that an at least 5-year support plan is proposed for the new technology to illustrate that it is sustainable.

4. Help Universities Build Lasting Partnerships with their Vendors

Trust is a powerful emotion. Where there is confidence, there is team empowerment and higher productivity. A lack of trust could force the project team into a rigid, sometimes stressful work environment which can lead to performance issues. If contract negotiation is rough and restrictive from the beginning, question the vendor’s ability to build partnerships with its customers. Sometimes it is best just to walk away if trust cannot be established. In any situation, if you are staying in a relationship for fear of the terms of a contract, then it is doomed to fail and will make those involved miserable until it ends. The project that is relying upon technology supported by a decaying vendor relationship will have extra challenges. Help the university check references and review performance during your project, and save the information to evaluate the vendor for future project opportunities. Vendors with a high degree of trust earned through successful implementations should be given preference for new projects.

5. Help your Team Avoid the Temptations to Implement New Technology or Designs Just Because They are “Cool”

All technology selections should be about bringing a solid value to the university.

Just because a new piece of technology is innovative does not mean that it needs to be implemented. All technology selections should be about bringing a solid value to the university and/or to minimize any risk of the technology becoming obsolete (which is to ensure the technology is not risky but is sustainable for years to come).

6. The Devil is in the Data

Quality data is essential for project success, but the existing information is not always in the best shape. Help your university understand its data requirements and “clean” the existing information as much as possible. Choose the best design and platform to meet business needs using dimensional models for reporting optimization and normalization for transactions. Timely business involvement is critical with any data conversion definition, information cleansing, mapping, and validation activities. Begin testing early to avoid significant data issues and delays late in the project.

7. Slow Technology Performance will Delay your Go-Live

Users of a new system will not tolerate slow system responses and will not allow a go-live if the solution does not meet their existing service levels. Document the performance Service Level Agreements (SLAs) and have vendors commit to them. Build performance test checkpoints early within your project plan to avoid problems close to the go-live date. Performance issues are complicated and require adequate time to fix.

We want to thank Greg for letting us publish this series here. If you’d like to learn more about his Higher Ed Project Management expertise, feel free to follow him on Twitter.