The Business of Project Management in Public Higher Education
|
|
by
Patrick Benson, PMP
Tuesday, June 29, 2010
|
|
Patrick Benson, PMP, Director of Administrative Computing, Northern Arizona University
Examining IT project management in public higher education starts with the question often asked by legislators, voters and the media: "Why is it so expensive?" Most of my body of work has been within this market sector and I've often been challenged with questions that are variations on this theme. While there are few clear answers, there are core, fundamental differences between the public and private sectors that increase costs on all public sector IT projects, and there are environmental factors that exacerbate the problem in public higher education.
Project managers in the public sector are burdened by challenges that their peers in the private sector are not. These challenges go to the heart of running a government agency as a business (not "like" but "as" a business - meaning in the most cost-effective manner possible without a profit motive).
First, government is inflexible in both market sector and market performance. A government agency may be run as efficiently as a private sector firm - but there is very little market sector flexibility. Legislation drives what government agencies will do, and generally who in the government will do it, and how it will be done, and how much it will cost, and how much may be charged to users, and when rules start and when rules end. Notice that in this list of questions, "Why a government agency does something" is missing. Government agencies are legislatively driven. The answer to the "Why?" question runs along the lines of, "Because you're told to do it." The most basic business plan question, "Why do this instead of that?" cannot be answered. Government agencies stand behind the "consent of the governed" rule of law. By and large, government agencies do what they do because their target audience's elected officials tell them to do it.
This legislature-as-driver limits a government agency's ability to change products or prices, or move quickly to expand or improve services. Why? Because public sector inflexibility cannot respond as quickly as the private sector to market changes - the model fails to consider that the market (not a legislature) is the most efficient and effective allocator of resources. Government marketing often fails because an inappropriate mix of goods and services are offered at market-rate prices. Government agencies fail when forced to compete in the marketplace because of the inherent inflexibility of the public sector business model. The best profit and loss position a government agency should seek is to break even - which is total failure in the private sector.
Second, government is an open environment. Nearly all public sector products are public property. IT project charters, stakeholder registers, scope statements, schedules and plans, baselines, costs and budgets, risk registers and response plans, contracts, procurement plans and all the backing materials are subject to exposure and examination. Behind public sector projects, one way or another, stand public funds. Although the specific rules vary among jurisdictions, many government agencies now find little in the way of legal backing in the technique of marking IT project documents as "drafts" or "working papers" to keep them from public scrutiny. Routinely, one reads about an agency accused of failing to meet their legal requirements to make public this or that document . The courts usually come down on the side of the requestor and the cost of defending this indefensible position can be significant.
This openness can be seen as another vector of inflexibility; there are real dollar and time costs to the openness required. Consider build-versus-buy decisions and the amount of time spent on, and public scrutiny of, RFQ or RFP responses. Competition is fierce and losers often litigate; either seeking to change the outcome, to punish the contract's winner, or punish the agency that made the award. Openness drives delay, and time is money regardless of the market sector.
Third, mandates have unfulfilled costs. Two recent changes are bringing significant administrative burdens. Federal Stimulus Funding is bringing money to state and local government agencies, and GASB-51 is bringing changes to accounting procedures. There has been precious little recognition of the downside cost of Stimulus Funding - of the strict performance and completion deadlines or new transparency requirements. Changes to GASB can bring the need for detailed time collection and reporting to major software development efforts regardless of the funding source. The requirements take time to analyze and implement. They delay a project's progress. Here, again, time is money.
Fourth, collaboration brings a cost burden. This is perhaps more applicable to higher education than other government agencies. Higher education institutions are environments of collaboration - and this strength can work against strong stakeholder and change management techniques. It can be difficult to say "no" when a department without an identified stakeholder or subject matter expert in a relevant area of the project wants to be involved in project meetings or exercise veto power over work in which they have no business stake. Control battles are a way of life in the public higher education market sector, and a disciplined approach to gathering requirements and setting scope when consensus is demanded can be vexing.
So, how to succeed? Project managers should focus on doing the job right, on doing it within the constraints, and getting it done right the first time. This is a more cost-effective approach than spending time explaining and attempting to defend work and processes after the fact.
What does "do it right" mean? Well, doing the same thing again and again while expecting a different outcome is insanity, and we don't want to go down that path. In my opinion, "do it right" means having a consistent, documented and functional project methodology that is updated with every success and failure, and can be followed from project to project.
There are probably as many ways to manage projects as there are readers of this article. Until recently, my project management training dated to a college course in 1974 or 1975. Yeah, I know that dates me a bit. To set the record straight, I do have a dog-eared System/360 BAL green card, my collection of flowchart templates includes one for HIPO, and I still remember how to patch-cord a card interpreter and make printer control tapes. Given this aging knowledge and facing a dozen new projects for my portfolio, in early March, I spent a week at a Project Management Institute-certified training program. Although I cannot say I'll blindly follow everything, it is fair to say that the PMI project management model has far more going for it than going against it. The model provides a framework for being a repeatably successful project manager and it provides independent air cover for the inevitable "Why do we have to ...", "Why did you..." and "Why can't we just...." questions that accompany every project.
Here at Northern Arizona University, I've tasked three project managers and myself to use the PMI framework on four efforts with significantly different sizes, scopes, audiences and timelines. One project is to implement the Oracle/PeopleSoft Financials package for use only with Grants and Contracts (feeding to and from a disconnected third-party financial system - a constraint bringing a unique set of challenges). The second project is to acquire and implement imaging and workflow to automate four common campus forms. The third project is really a program - a collection of 13 smaller projects aimed at helping our students stay on track toward timely completion of their degree. The fourth project, mine, is to automate collecting, retaining and serving faculty activity information.
Where do I suggest starting? Right at the top of the PMI list - Develop Project Charter.
Under the PMI approach, the project charter is arguably THE keystone document for a project. Sitting at the intersection of Initiating Process Management Group and Integrated Project Management Knowledge Area - the project charter is the first point where an institutional audience hears about the efforts envisioned, who is backing it and the potential cost. Most importantly, the charter formally initiates a project and allows the commitment of resources. No charter, no spending time or money on the project. My advice - get it early, get it formal, and get it approved by upper management. In addition to authorizing the project, a solid, complete charter serves to document initial requirements that satisfy stakeholder needs and expectations, and defines the initial assumptions, risks and constraints faced.
The keyword there is "initial" - watch out for the extensions, modifications and dreaded creep. Change is inevitable. It just has to be managed.
|
|
|
|
Patrick Benson, PMP
Patrick Benson, PMP, has worked in all phases of government administrative systems development, support and management for decades. Today, he is the Director of Administrative Computing at Northern Arizona University.
The major components of his current portfolio include Oracle/PeopleSoft Human Capital Management (HCM) and Campus Solutions (CS), the CGI/Advantage Financial suite, and an Informatica and SAP/BusinessObjects data warehouse. Major challenges over the next five years include: getting the PeopleSoft Grants and Contracts version 9.1 modules installed without using the full financials package, directing the technology as NAU changes focus and expands into new university structures, assuring the current production PeopleSoft version 8.9 CS and HCM applications are split and up-versioned to 9.0 CIM (CS) and 9.1 (HCM), extending the data warehousing products to include portal-based dashboards, and either up-versioning or replacing the installed financial system.
Patrick and Shirley, his wife of 40+ years, enjoy living in Flagstaff - especially visiting and hiking the front and backcountry areas of Arizona's Canyon Country; the Grand, Oak Creek, Walnut and Sycamore are favorites. Both freely admit, however, they did not enjoy shoveling 12 feet of snow during the winter of 2009-10.
|
|
|