Glen Alleman

Glen Alleman is Vice President, Program, Planning, and Controls at Lewis & Fowler.

Glen’s background includes Project Management executive positions with 25 years experience, and he led the creation of Lewis & Fowler’s Deliverables Based Planning (sm) method as it is applied to aerospace, defense, and commercial enterprise projects.

Glen has an excellent blog at http://herdingcats.typepad.com.

Josh: How did you get your start in project management?

Glen: I started my career as a software engineer in the radar/sonar business. I was a fresh graduate student in physics and moved my skills in digital signal processes from particle accelerators to radar systems. I worked on digital filters and pattern recognition systems. I moved from those areas to realtime control systems for the vehicles that had the radar on board.

Over time I became interested in the business side of these programs and started to ?manage? the work packages of larger programs. When the aerospace business fell on hard times in the early 80?s I switched to commercial software development and managed groups of developers for a variety of products. Planning, budget, deliverables, staffing and requirements management were done in the traditional manner. As that market matured some of the agile processes started to be used and project management became more important for the business side of the project.

I switched back to aerospace and defense in the early 90?s as a Program Manager in a large Department of Defense initiative here in Denver. I had Project Managers looking after multiple decommissioning activities. since then I?ve been with a Program Management firm developing business and processes for our aerospace and defense sector.

Josh: Who do you look up to and have learned a lot from in relation to project management?

Glen: the President of Kaiser-Hill (the joint venture between ICF Kaiser and CH2MHill) created an environment where the Plan of the Week and eventually the Plan of Day was our paradigm for getting to closure under budget and ahead of schedule. During that period I met Paul Solomon, who has since retired from Northrop. Paul?s book Performance Based Earned Value influenced my concept of measuring physical percent complete. Also Nick Pisano guided us with his advice on how to use WinSight (then from C/S solutions) to integrate a large number of concurrent projects into a single Performance Measurement Baseline. Nick was the former PEO (Program Executive Office) for several Navy flight programs and is now the president of Safran ? an integrated program management system.

I received my best advice from my boss at Rocky Flats ? who created a collegial environment where we could try out new ideas around program management and ?learn? how to improve the process before we met with the real problems of getting a nuclear weapons plant decommissioned.

Josh: How do you stay focused on the MACRO project goals, and not get drawn into the MICRO?

Glen: I stick with the Integrated Master Plan / Integrated Master Schedule paradigm for everything. This approach defined what ?done? looks like in Significant Accomplishments and the Accomplishment Criteria (exit criteria) for the Work Packages containing the individual work activities. this approach is applied to IT, construction, and DoD/NASA programs. The owners of the Work Packages are accountable for delivering the Outcomes. The Program Manager (me) is accountable for removing any impediments to the work package progress.

This requires that everyone understand that if a Work Package manger is not up to the task, someone else will be given that work. This avoids any temptation to dive into the activities ?inside? the Work Package. There is a clear boundary between Master Plan and the schedule of the Work Package. This boundary is defined in a Responsibility Assignment Matrix (RAM) with the intersection of the Organization and the Work Packages.

Josh: How do you handle scope creep?

Glen: The Integrated Master Plan and the Work Breakdown Structure are mandatory. With these two description the scope is explicitly visible. Changes in scope only happened in an approved manner. Then cost and schedule impacts are also visible. Scope creep is needed in many instances. Uncontrolled, unapproved, and unassessed scope creep is the problem, not the scope creep itself. It?s managing in the presence of change that creates success, not trying to manage the change.