Loyola University Chicago

- Navigation -

Loyola University Chicago

Project Management @ Loyola

PMO Article Published



Project Management in Higher Education – Keep It Simple, Keep It Fresh

by James Sibenaller & Ray Pauliks

 

Tuesday, October 19, 2010

 

While an acceptance of more structured project management principles is becoming more of the norm than the exception in the corporate environment, formal project management methodologies are just beginning to gain a foot-hold within higher-ed.  All of us, at one time or another, have adjusted our project priorities in order to meet the increasing demands of our customers.  The needs of students, faculty and university administration within the higher-ed environment are extremely dynamic and call for an approach to project management that is easily understandable and adaptable at the same time.   The culture within the higher-ed environment demands this flexibility!  Over time however, this typically turns into a less structured and unrepeatable approach to implementing projects and project management.

 

So, how do you bring a more structured approach to project management that is flexible and easy to understand to an environment that seems to be constantly changing?    In this article we’ll walk you through what has worked at Loyola University Chicago, how we have addressed some of our “challenges” and how we have implemented project management that is a “right fit” for our culture.

 

Assuming that you are in higher-ed and have been tasked with implementing project management principles within your organization, where do you begin?   Start by viewing this process as a project itself and as with any project begin by meeting with your Sponsor.   Ask them to identify their requirements.  What is it that they really want?  Have the Sponsor identify their Critical Success Factors.   Understand how your sponsors will define and measure “success” for project management.  In the conversation, determine the business needs that they are trying to address and the value that is expected.   As important as identifying what your Sponsor wants and expects, discuss how ready the organization is for change and for a more structured approach to project management.  Understanding the organization’s readiness and willingness to accept a little bit of structure will go a long way toward planning your roll-out strategy and reducing your frustration, ultimately leading to a more successful implementation.

 

Once you have captured and documented your Sponsor’s expectations, build your roadmap.   Your roadmap should outline where you plan to Start and where you plan to Finish (remember your Sponsor’s expectations!)  In between your Start and Finish will be the route (steps) you will take to get to the Finish, where you plan to take a break (rest stops), where you plan to take check points (review your map) and how you plan your improvements(re-routes).   Sounds like a project plan, doesn’t it?

 

Where you start and where you finish is up to you (and your Sponsor!).  Every organization is different.  Don’t assume that what worked somewhere else will work in your current organization.  Understand your culture.  Then develop your methodology to be flexible based upon the size, scope and risks of each project.    There is no one size fits all!  Our templates and approach to project management are PMBOK based and tailored to the size and scope of each project.  For smaller projects, we use less structure resulting in a more agile approach to project management.  For larger strategic or enterprise-impacting projects, we use more documentation and more structure.  We call this our “right fit” approach and it has worked well in our environment because it enables our project managers to match their approach to the expectations of their constituents on an effort by effort basis.  The key to success is to start by identifying what components of the project management methodology will be utilized for the engagement.  Then taking frequent checkpoints along the way to ensure that the process is working, or make adjusts where necessary.

 

It’s important to remember that, like Rome, your PM methodology and structure will not be built in a day, or a month, or a year!   Basic piece of advice:  Be prepared to “crawl, walk, and then run”.  Expect change to come slowly and understand the culture you are working within.  Plan for it to be deliberate and take time.  Our PMO has been in place for approximately 4 years.   While the methodology has become more widely accepted across the organization, we continue to adapt our project management approach to the changing needs of our users and input they provide.  In time, we will be ready to “run”, but not yet.   Right now we are just walking at a nice steady pace.

 

How do you “crawl, walk and then run”?   What does that mean?  For us it’s about the willingness to start with the basics and to expect small incremental acceptance of the methodology as you go.   The “K*I*S*S” (Keep It Simple Silly!) principle really works in this case.  We started by fostering the usage of a Project Definition document.   The more we used it when initiating our projects, the more folks outside of the Project Management Office (PMO) began to accept it, ask for it and even begin using it for their own projects.  When we tried to implement more complicated processes, like detailed Risk Management Planning, we were not very successful.  The organization just wasn’t ready for that level of structure.   So we simplified our approach to Risk Management Planning and adapted to the needs of our customers.  This “right fit” approach brought improved results both in our project outputs and in the acceptance of project management principles.

 

In your initiation phase of the project it’s also keenly important to clearly define the roles and responsibilities of the project team members and, believe it or not, the Project Manager.  Don’t assume that everyone identifies a project manager in the same way.  Just because you understand what a project manager does, doesn’t mean that your sponsors and stakeholders have the same level of understanding.  Some folks believe that a blended PM / BA role is what’s appropriate.  Ultimately, it all depends on what works for your organization.  Just be sure to address this up front in order to avoid confusion during your roll-out.

 

For tracking tasks and activities, we started by simply using Excel spreadsheets.  We found that identifying tasks, dates and status within the spreadsheet made it easier for folks to accept a certain level of detail.  If we had started by introducing work breakdown structures and using a project management tool right-away to track project activities it would have been too much too soon.   Instead, we introduced formal project management tools only where the need to manage tasks and dependencies at a specific detailed level was identified.  The PMO continues to use a formal PM tool because of the additional functionality that comes with that application.  Other project managers may simply use spreadsheets to track progress.  It all depends on the PM and the scope of the project.

 

In order to “close out” a project, we hold a simple project closure meeting.  We have two primary objectives for this meeting.  First we focus on the project itself.  We ask questions such as: Did the project meet the requirements and expectations of the Sponsor?   Are there any open issues?  Is the ongoing ownership clear?  Was there appropriate knowledge transfer and documentation?  Secondly, we focus on the process itself so that we can sustain current project management successes and improve on any weak areas.  Here we simply engage in a discussion regarding what went well and what could we (the project team) have done better.  Specifically, we don’t focus on “What went wrong?”   Asking instead “What we could have done better?” gets the team focused on future improvements to the overall process.  It fosters communication and creates an environment for “open” dialogue that you just might not get if you try to discuss and identify things that are “wrong”.   It’s a more positive approach to getting at the same thing.

 

It’s important to mention a few “pit falls” to avoid or “lessons learned”.   Make sure that you have developed a comprehensive overview of the project management methodology.  This is important for both your external customers, your project teams and for the project managers themselves.  Explain why the methodology is being implemented.  Focus on “What’s in it for them?”  And, where possible, engage the users in the development of the methodology.  Ask them what they want the process to look like.   Develop an understanding of how they envision project management working within the organization and balance that with best practices and sponsor needs.  We found that our methodology was rolled-out without these key activities being formalized.  As we tried to enhance what was there, we encountered resistance.  Why?  Not because they were unwilling.  But because they did know what had been developed, why project management was being implemented or how more structured project management would help them.

 

In closing, continue to build, grow and transform your methodology.  Plan to make continuous small incremental adjustments.  Earlier, we mentioned that the roadmap has a point where you finish.  But that’s not entirely true.  Once you get to the finish, you need to reflect and go back to the start.  In essence, there is no end to building and improving your project management methodology.   You update your path based on what you learn along the journey.   It’s a continuous process.  Periodically survey your users to identify what’s working and what needs to be changed.  Avoid complacency and over time you will have established a robust project management methodology that will be the envy of others!

 
James Sibenaller & Ray Pauliks

 

James Sibenaller is an IT Director at Loyola University Chicago responsible for the Project Management Office, Enterprise Architecture, Information Security, Quality Assurance and Change Management processes.  He is the primary driver behind the creation of IT Governance processes and best practices within the Information Technology Services department.  In 2008 he and his peers received the Most Effective IT Team Award from the Chicago Chapter of the Association of Information Technology Professionals (AITP).  Jim is a ten year member of the Project Management Institute (PMI) and is Foundations Certified in ITIL.  He holds a Bachelor of Science degree in Computer Science from Aurora University in Aurora, Illinois.

 

Ray Pauliks is a Senior Project Manager at Loyola University Chicago where he plays a significant role in establishing and defining PMO processes through-out the university. Ray has over 20 years experience in IT and Project Management, primarily in corporate settings with Fortune 200 companies. Ray completed his post-graduate studies at Benedictine University Lisle where he earned an MBA with a concentration in Finance and an MS in Management Information Systems. He holds a BA in Business Administration from Saint Xavier University Chicago.   Ray is also a member of the Project Management Institute (PMI).



Loyola

CHICAGO | ROME | BEIJING

LOYOLA UNIVERSITY CHICAGO · 1032 W. Sheridan Rd., Chicago, IL 60660 · 773-274-3000
webmaster@luc.edu · Text-only Version · © Copyright & Disclaimer 2011

Notice of Non-discriminatory Policy