|
|
|
|
|
Government Software Project Management 101
|
Software project management in the federal government is not for the faint of heart. It is one of the hardest and most demanding jobs in the information technology (IT) industry. When costs go over budget, the project manager (PM) takes the heat. When the technology does not work, the PM is responsible. When limited resources make the death-march schedule impossible, the PM has to explain it to the boss.
PMs often have three customers: the up-line manager, the dotted-line manager and the application end users. Those three customers often have different "theories" on what needs to be done, and how work really gets done, forcing the PM to become a master arbitrator and salesperson.
And, IT project management requires the PM to have at least some level of knowledge about the technology he/she is managing. A construction project manager or an accountant would fail if placed in charge of a software development project, not because people from diverse fields can't become good PMs, but because there is no substitute for formal training and IT project experience. The skills are that different. Plus, most good PMs have lived through at least one catastrophic failure (read "learning experience").
Case Study: Developing an Asset Tracking System
Outlined below is a fairly typical starting project management scenario. The organization has a need for an asset tracking system for the entire division to include office furniture, desktop computers, field equipment, and high dollar consumables. The PM may have taken a project management class and have some background in developing office automation applications using MS Access and Excel. The facilities management department (which is under accounting) has a spreadsheet that it uses to keep inventory of the office furniture. The MIS shop has a tracking database for computers and software. Field equipment is managed by Operations. Nobody tracks consumables.
Getting Started
There are five basic core areas for planning and launching this kind of project. While organizations with different IT maturity levels have different CIO-spawned IT governance controls, most organizations that follow the Capital Planning and Investment Control (CPIC) or OMB 300 include the following aspects in their IT acquisition programs.
Business Sponsorship — A leader on the business side needs to identify the high level requirement and sponsor the project. Without this kind of support, there officially is no project. Moving forward without this support may cause the project to solve problems that don't exist and place the PM's career in danger.
User Buy-In — The "if you build it they will come" approach does not apply to business systems. No matter how technically perfect the solution, if the users do not use the new system, it will fail. It is the PM's job to sell the project to the staff. There are two tactics to ensure user buy-in. The first is inclusion of the end users' needs in the requirements process. The second is aggressive marketing, a function that may be new to many PMs, but is, nonetheless, essential.
Resources and a Business Case — Nothing can happen without money. Funding often comes from the sponsor or possibly as part of a budgeted line item. However, the ability to execute those funds is dependent upon procurement and IT governance policy. Many agencies have dollar limit thresholds that require approval up the management chain as the dollar amount increases. And, every move up the chain may require more business planning. For example, many large dollar projects will need OMB Exhibit 300 submissions. In any case, the PM must be prepared to present a strong business case at all times.
Lifecycle Operating Agreements — A new software application will most likely run on someone else's network and hardware. It may require interfaces to and from other systems. And it will need the helpdesk to provide support. The system may also contain sensitive information that requires special security procedures. The PM needs to identify and plan for all of these issues up front or the project could be blocked at the most inconvenient time. And, time is not on the PM's side.
Project Governance — This is, perhaps, the area over which the PM has the most direct control. Here the PM can identify the processes for change requests (CRs) and defect requests (DRs), set project milestones and documentation requirements, and define the development methodology. Scope and scale of the project often drives the governance requirements, but most organizations require some level of project governance as part of the funding request.
The Details
The basic tasks of a software development project map to the five core areas outlined above regardless of the development methodology. The graphic below lists the steps that most IT projects must go through and how they feed each other and the core areas mentioned above. While different organizations may use different language, all projects should map to these tasks.
It is essential for PMs to gain the support of others within the organization to ensure the process runs as smoothly as possible. At the same time, the PM is the driver of the process. The PM's job is to keep things moving day in and day out. A PM who is not operationally minded or who has multiple other collateral duties may want to pass up an opportunity or learn by being a Deputy PM before taking on full responsibility for a large project.
For more information on how Pivotal Insight can assist you with IT strategy, please visit us at www.pivotal-insight.com.
|
Free trial
Subscribe Now
|
