Modern IT Program Management: An Introduction

If you are in IT, whether you are a government employee or a vendor, an executive, manager, programmer, architect, business analyst, or financial analyst, you will either be overseen or exercise oversight over IT programs. Oversight is a critically important function. But it is a function that can become bloated and wasteful, or ineffective.

In the series that follows, we will explore what is most often overseen during an IT program and consider where serious diligence is likely to yield better results. We will consider shortcuts that reduce oversight without reducing good outcomes. We will consider oversight of both agile and waterfall projects and discuss issues associated with both time and material and fixed cost accounting. We will discuss Buy vs. Build options in light of modern software development best practices and think about what modern technical guidelines could look like.

There are a few fundamentals to start.

Let’s agree that the objective of oversight is to improve the outcomes of IT programs and that good outcomes mean cost-effective proposals, business owner satisfaction with the result, within budget, as soon as possible. The reason for the less-obvious objective of ASAP is that “cost-effective proposals” come with some return-on-investment (ROI) and the sooner the return starts, the better.

I will assume that oversight should be held to the same standards projects are held to. Oversight should have a set of performance metrics over a portfolio of programs. If outcomes are not improving, then oversight should be reviewed and adjusted. If oversight is bloated and delaying delivery, then the cost of that delay should be accounted for and reduced, if possible.

This is an important concept. If oversight delays an implementation by a year that would save $20M/year in order to perfectly optimize costs with a further reduction of $1M/year, then maybe the oversight delay is not justifiable. If oversight delays an implementation by a year with no clear justification other than a sense of due diligence, then maybe the delay is not justifiable. We will consider the ROI of each phase in a project lifecycle and ask if we could reduce the cost of oversight without increasing risk.

Finally, we will consider where the same information is overseen by multiple overseers and ask if the redundancy and associated cost improves the results.

Rather than espouse a particular project lifecycle, we will walk through a generic process.

The first phase will define the project and provide the business justification. Note that the business justification is not the same as the ROI. ROI cannot be specified until an approach is defined and the associated costs are estimated. The project definition will provide a description of the scope used to frame all of the subsequent phases.

In the next phase, the alternatives available to satisfy the scope are considered and the cost and risk profile of each alternative is evaluated. The major deliverable from phase 2 is a selected alternative. If the project is being developed using waterfall, then high-level business requirements are required to guide the selection process. If agile methods are used then a substantial, but not exhaustive, set of user stories must be composed. We will argue that agile user stories represent high-level business requirements so that it is not necessary to choose agile or waterfall in this phase.

The third phase defines the approach to implementing the selected alternative. “Approach” represents a high-level plan. Here waterfall or agile methods are selected and outlined for the buy or build alternative identified in phase 2. The steps required to get from here to the start of development are outlined for the selected approach and alternative and the high-level milestones associated with development or deployment are mapped. The approach to oversight and reporting is defined. The approach to assure quality and acceptance are defined. The approach to building out required software and hardware infrastructure is described. The approach to vendor selection and contracting is described. In other words, a statement of the work required is delivered. Importantly, in this third phase a cost estimate is delivered that suggests the budget required to perform the work.

If the work defined by the approach requires outside resources then a fourth phase is executed to compose a solicitation for hardware, software, and/or services. The solicitation is delivered to the appropriate vendors, the results are evaluated, and a vendor is selected.

Phase 5 is the execution step. I’ll suggest here in the introduction that this is the phase where oversight can be most effective and the phase where often, the least oversight is performed. The means to oversee execution vary, from waterfall, to agile over builds and buys. We will consider how some modern technology can be brought to bear to provide nearly complete transparency into project execution.

So now you know what to expect. I hope that you find the series thoughtful, and a little wacky. Thanks, in advance, for your attention and consideration.

Rob Klopp is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.