How do we best apply lean to IT project management in a service oriented government agency?

From a Lean Six Sigma perspective, you’d be looking at an evaluation and re-engineering of the project management processes and deliverables from the ground up. At a high level, Lean is all about waste reduction. Lean is not a cure all, but it can in fact have a significant impact on productivity by reducing waste. Waste reduction

Applied to a PMO, it’s all about doing work that matters to completing projects on time and reducing or eliminating work that doesn’t contribute to that end. Effectively, you want your PMs doing more coordination and communication with project teams driving results and less time producing reports and useless documentation. If it takes 2 hours to produce a report that will only be reviewed if there’s a problem, that report should only be created if there’s a problem.

“Reviews and reports” can be a great place to start because there is usually so much low hanging fruit. First steps should include gathering all of the existing operational guides, how-to’s, best practices, document templates, and any documented process flows and reviewing them. See how they all fit together and identify purposes, consumers, dependencies, and overlaps for each item you evaluate. This step will give you a clear view of the opportunities for consolidation and truncation of processes and documents.

Once you’ve eliminated (or at least reduced) the redundant and useless items, it may be good to evaluate the items that survived the first pass in more depth. Go through them section by section and make sure the intended consumers are actually interested in the data that’s being provided. Often you’ll find that something has been done a certain way because someone who retired or left several years ago wanted it that way. The goal here is to make sure you’re only producing what people need today. Less is more.

Once documentation and reports are cleaned up, some other areas that can yield great results are work intake processes, hand-off and project close processes, and resource management/capacity planning processes. These are usually poorly documented and everyone does them differently. Standardizing can yield a big boost in productivity.

Finally, a few words of caution, wielding the “waste hatchet” is great, but you must be very careful to only cut what is truly unnecessary.

Consolidate before cutting:
This means if something appears unnecessary first see if you can consolidate it with a similar activity reducing overall work before you cut it out completely.

Consider Quality:
Efficiency should never come at the cost of quality. If removing an item or step results in increased risk of error, steps should also be taken to compensate.

Keep good notes:
In addition, keep careful notes of your action and changes so if you need to undo a change, it’s easy to see where something was and put it back.

Build consensus, get buy in:
Always know who the stake holders and consumers are. Make sure they’re on board with changes and modifications to processes. All changes should be reviewed and approved IN WRITING by all stake holders. Also be sure that the person(s) approving changes are actually authorized to do so and have considered all important factors such as other agreements, SLAs, and/or contracts that may be impacted.

There is, in the federal sector and many large private sector organizations, a strong tendency to focus on the IT very early in the process. That never works well because it ususlly occurs before a really good picture of the goals of the effort are understood and inculcated into the various players. The result is usually means acquisition of lots of gee-whiz technology that makes some careers (at least for a short time) but does little in the end to properly provide the service needed.

To support this thesis, I would offer some of the really successful projects in the federal government:
1. Defense Intelligence Agency started in 2002 with a mandate from its director to create a usable and comprehensive library of intelligence assessments. The mandate included a specific direction that the effort focus on the content rather than the systems. Several years later, the Library of National Intell was opened: fully XML searchable and growing at thousands of assessments per week, all on what would be considered a shoestring and without mangling the IT infrastructures of the 15 DIA units involved.
2. OMB started an effort to improve the budgeting process using tiny funding and no major IT acquisitions, but focusing on what the budgeting agencies really needed. The effort has blossomed with a wiki used by thousands of agency workers and the development and shared use of specific applications by agencies. The effort never made IT news but its "under the RADAR" approach focused on shared problems and shared solutions.

Unfortunately, IT has become the centerpiece of too many efforts, clouding the very reasons why the effort is being undertaken. This is not to denigrate a major role for IT, but to suggest that "lean IT" should mean that the gadget guys hold their tongues until a real subject matter and service analysis is completed, then act to support and realize the goals of that analysis instead of taking control and moving ahead for its own benefit.

Leaning is an interesting concept because we tend to apply it to units of work that may not lend themselves to the effort. If you are trying to improve quality, then the value you are shooting for, from a defect standpoint, is 99.99966% defect free. If you are trying to lower costs- let’s say from a service desk then you really need a basis from which to start. If you know that the industry average is 6 people to accomplish the function and you have 25 doing it then you have a target (6) and a starting point (25).

The problem is, in leaning, organizations don’t always have a target that has a foundation in some kind of mathematical formula. In our organization, we use a parametric model that has 2,700 IT contracts as a basis and we simply enter quantities of things like workstations, servers, locations, hours of operation, etc. This is our starting point to which we have to add or subtract elements of work. In the service desk example, we could add remote password reset and self-help functions which dramatically reduce the costs.
In my mind, leaning can also mean a balanced approach in which some functions are outsourced (not offshored), other functions are actually increased depending on how you derive units of work or where quality needs improvement, some might be consolidated, and still others you will just drop because the returns to your constituents just don’t merit the time. Each tactical component of your strategy must then have a measurable outcome of your expectation of quality. In the service desk example it might include 85% of the incidents are solved in the first contact and 96% of the calls are answered by the third ring.

I just don’t see the magic in it if you sit down and get into the real detail of what you are trying to accomplish. Obviously, if you don’t have the time then hiring a consulting firm for support is in order. But remember, you will have to devote time to this anyway as the consultants need your level of understanding of your organization before they get begin working on the details.

Applying LEAN to project management processes can be tricky given LEAN was originally developed for and applied to manufacturing. Now there are many examples of applying LEAN to service processes such as software development. Many software development efforts are poorly organized, resulting in rework, unbalanced workloads, and other forms of waste that harm both productivity and morale.

Though some analogies can be drawn between software development and project management processes, they are often quite different. Identification of waste is the first and foremost goal of LEAN, and many folks have been able to identify process waste in software development, but identifying waste in project management processes will be more difficult given there is likely no existing baseline and project management processes tend to be situationally specific. It is much easier to apply LEAN to processes that are repeated again and again where the identification of value-adding work vs. non-value adding work is more straightforward.

Here is a quick list of the type of waste LEAN aims to eliminate:
- Rework
- Wasted motion
- Wasted intellect
- Wasted time
- Inventory waste

LEAN approaches eliminate waste by improving:
- Flow processing
- Load balancing
- Standardization
- Segmentation
- Quality ownership

LEAN also necessitates changes in culture and behavior and it requires executive level sponsorship. One of the greatest challenges will be gaining the participation of key project management process stakeholders. Assembling the appropriate parties who are served by project management processes could be very difficult given many of these folks have never been tasked with participating in the design, implementation or management of these processes.

LEAN also requires changes in management systems such as roles, metrics, and performance measurement. Last but not least, LEAN takes time and it never ends – it is a continual evolution. LEAN requires continual management of the process by a devoted and passionate process owner.