Agile and lean project management

a Zen-like approach to find just the "right" degree of formality for your project

Abstract

Waste no energy. Minimize paper work and bureaucracy. Practice PM as a Zen art. Do just right planning and control. Be adaptive. Find the right degrees of interpersonal relations, communication, granularity, and compliance. Balance formality and flexibility. Scale PM based on project attributes and compliance needs to meet essential requirements.

Introduction

Project management seeks to “perform the right projects right” so that customers, sponsors, regulators, portfolio managers and performers are satisfied, if not thrilled. Both a project centric and organizational perspective is needed to create a healthy process.

Picture the most effective project you know. How does it look and feel? Waste no energy. Minimize paper work and bureaucracy. Do just right planning and control. Adapt. Find the right balance among interpersonal relations, communication, granularity, and compliance; formality and flexibility. Scale PM to project needs. Focus on objectives. Question everything, including your own beliefs and resistance to either flexibility or discipline. In short, work lean and agile.

Objectives

Working lean means eliminating waste. Being agile is to be adaptive, resilient, flexible and appropriate to the situation. Combining them we find the “just right” level of formality in our projects so there is no excess and no insufficiency. Like the martial artist, the project team wastes no energy to get the job done.

The right PM approach is different for a large complex project in a highly regulated environment than it is for a small project in an informal environment with a close knit dedicated team. In all cases there is an optimum level of lean agility.

Issues

Project managers, performers, clients, sponsors, regulators and functional managers are challenged to manage projects in complex, dynamic settings to meet both project and organizational objectives. There is conflict between the extremes of under and over documentation, planning and control.

How do we standardize the PM approach without overburdening the staff with unnecessary paper work or bureaucracy while promoting adaptive action?

People resist formality and standardization because they feel the burden is too high. This resistance can result in “throwing the baby” (good formal PM practices) “out with the bath water” (excessive formality). Many stakeholders feel that formal PM wastes time and money, restricts creativity and flexibility and increases the risk of failure. Others argue that formal PM is essential to success.

Note the paradox. Project management has at its heart improving project performance, yet there is a credible belief that it can do the opposite. But, there is no conflict. Formality is not the opposite of agile and lean. In fact, it is a prerequisite for them.

Balance

The key is to find the right balance to enable control on the portfolio program and project levels, maximize project and resource efficiency, increase flexibility, reduce risk and promote ongoing improvement.

This balance is particularly important when regulatory compliance is an issue. For example, where there are regulatory requirements for strict adherence to a defined process the easy way to comply is to create a one-size-fits-all standard and force everyone to follow it. But this is too costly given its impact on effort, customer service and duration.

Even in highly regulated situations there is flexibility. Variance from the standard is permitted if it is justified and properly authorized.

Systems and Processes

A systems approach applies general systems theory to the dynamics of organizations, products, processes, and people. Anything can be described as a system made up of people, organizations, things and their interactions.

Processes are the actions in systems. “A process is a set of activities to accomplish something; a means to an end. Anytime there is a result, a process produced it. It is the key to performance.” (Pitagorsky, 2006, Chapter 9) To influence the result, address the process.

Process consciousness means knowing the process steps and their effects. It is a prerequisite for adaptability and continuous improvement. Albert Einstein defines insanity as “doing the same thing over and over again and expecting different results.” (Brainy Quote, ¶ 78)

The ability to work lean and agile is based on taking a systems and process oriented view.

Lean

“Lean” is a quality improvement and management philosophy that began in manufacturing. Its principles can be applied in any process. Its focus is on waste reduction while creating a better workplace through “respect for humanity.” Quality, production time, and cost are improved by eliminating waste.

In project management there are wastes like excessive documentation, excessive planning and control, unproductive meetings, avoidable rework, excessive definition of detailed requirements, unproductive multi-tasking. Lean PM eliminates these wastes.

The seminal book Lean Thinking introduced five core concepts: 1) Specify value in the eyes of the customer 2) Identify the value stream and eliminate waste 3) Make value flow at the pull of the customer 4) Involve and empower employees 5) Continuously improve in the pursuit of perfection. (Wikipedia, ¶ 5)

1) Specify value in the eyes of the customer –

Clearly identify objectives and requirements and use them as acceptance criteria. Doing the right projects right means satisfying the customer, and, more broadly, the needs of all stakeholders.

2) Identify the value stream and eliminate waste –

“A value stream is all the actions, (both value added and non-value added), that are required to bring a product through the main flows essential to nearly every product.” (Industry Forum, ¶ 82) It is the process.

Identifying the value stream enables analysis to pinpoint unnecessary steps and the ones that overly burden resources, and impact risk, relationships and quality.

3) Make value flow at the pull of the customer

In manufacturing this means don’t make the widget until there is a demand for it to minimize inventory costs by manufacturing just-in-time. But, Theory of Constraints says that the process should pull work as the critical resources (people, work stations or machines) are available to fill them. The message is, moderate the flow of projects to the performance group based on the group’s capacity to perform them. This helps to avoid overloading the resources and to minimize multitasking. At the same time make sure that every project addresses a meaningful need.

4) Involve and empower employees

Since the people who do the work generally know more about doing it then anyone else, involve them in process planning. Empower them to adapt the process, within clearly defined constraints, to the needs of the situation. At Toyota, Lean includes cultivating a human friendly and supportive environment. It is not just about reducing costs at the expense of employees and business partners.

In project work, some of the most egregious errors can be eliminated by involving the team in estimating, scheduling and other aspects of planning. The tendency for project managers and functional managers to commit their teams to schedules leads directly to late delivery, quality shortfalls and morale problems, resulting in customer and sponsor dissatisfaction, avoidable rework and the turnover of the most valuable employees. Avoid short sighted “efficiencies” like minimizing up front consensus building and eliminating administrative support.

Empower team members to critically assess their process and recommend improvements within individual projects and across multiple projects.

5) Continuously improve in the pursuit of perfection

The kaizen continuous improvement approach uses process measurement and review, problem-solving and analysis techniques involving managers, clients and workers. Kaizen relates to finding and eliminating waste while promoting increasingly more effective performance.

Agile

Agile is “moving quickly and lightly; “sleek and agile as a gymnast”; “as nimble as a deer”;…” (Wordnet, ¶ 1); Mentally quick; “nimble wits” (Wordnet, ¶ 2); “Refers to the speed of operations within an organization and speed in responding to customers.” (MIT Sloan, ¶ 10)

Agility has been associated with the Agile software development approach (Agile Alliance ¶ 1), but agility applies to all kinds of projects.

Agile involves minimizing risk by performing project iterations that deliver meaningful results. Communication is real time, quick and informal and preferably face to face. Project participants have significant autonomy. Written communication and documents are minimized, not eliminated. Requirements are allowed to evolve.

Goals of the Lean/Agile Approach

The goals of combining lean and agile are to deliver performance efficiency and effectiveness through free flowing, meaningful communication, self-managed teams, and commitment to success. Managed change, and continuous improvement are integrated into the process.

The Relationship between Lean and Agile

Both Lean and Agile recognize the need for an open-mindedness that appreciates the complex interplay among efficiency, people, communication, and the delivery of meaningful results. But, there is a tendency for people to latch onto good systems as cure-alls. Combining the best parts of multiple approaches requires creativity and works against “process fundamentalism.”

Lean focuses on squeezing out waste to maximize efficiency, reduce costs and increase throughput and quality. Agile has as its primary focus delivering results by minimizing unnecessary documentation and control and maximizing open, organic communications. Lean’s focus on continuous process improvement, based on an analytical systems and process analysis of performance adds significant value to the generally more informal, single project focused intuitive approach of Agile. The informal approach moderates the analytical approach to keep continuous improvement itself lean and agile.

How to cultivate a Lean and Agile approach

Cultivating lean and agile PM requires managed change that applies essential PM principles to fit the needs of diverse projects in diverse settings.

The ‘Must Haves’ of PM

PM essentials are used as a benchmark for evaluating successful performance for individual projects and the organization as a whole.

At the individual project level, the essentials are:

  • A common written understanding of project objectives and constraints
  • A documented plan with a comprehensive activity list, at an appropriate level of detail, expected deliverables, and realistic schedule and budget
  • Common understanding of how the team will communicate and manage information
  • Clear understanding of roles and responsibilities
  • Performance monitoring and reporting
  • Managed expectations
  • Quality control
  • Post project review.

Risk management, communication and change control are embedded in the scheduling, budgeting, progress monitoring and managed expectations items.

Case Study

Following is a brief case study to provide an example of an agile and lean project and a point of reference for analysis of how best to satisfy the essentials.

The project was performed as a consulting engagement for a large global company to evaluate a high visibility, complex model for the client and provide a report of findings. Estimated completion time was about ten weeks. We would complete the project in twelve.

A senior project management professional with clear authority and in-depth knowledge of the project domain and his organization’s needs led the client team. People representing the critical stakeholders in the project supported him.

The consulting team was made up of a lead consultant who played both the PM role and a key performer role, a senior consultant with significant subject matter knowledge and experience, a senior consultant as project director, a support consultant, an administrative assistant and an account executive. The members of the team were in three countries with different time zones. All were working on multiple projects. Team members were peers.

Planning

A statement of work (SOW) and plan were developed to identify deliverables, major activities, interim deliverables, time frames and the project cost to the client. The client/vendor relationship and the policies of both firms made a formal SOW mandatory.

Virtual Team

Given the reality of a virtual project team and the agile principle of co-location, the team needed to adapt. The goal of co-location is to enable quick meaningful communications with minimal writing and to reinforce the team relationship. Co-location was not an option with a critical resource on another continent and the team members working multiple projects simultaneously.

We adapted to this need by first holding a two day face to face kick-off meeting with the client team. Detailed understandings of the client environment, deliverables, terminology, constraints, milestones at which interim results were to be presented to the client and the project modus operandi were agreed upon. We arranged for a web meeting site where we could work interactively in virtual meetings. We established basic document management and email standards.

In essence we enabled a “distance” environment that simulated the bull-pen environment that is recommended in the Agile approach. The virtual nature of the team and the reliance on both synchronous and asynchronous electronic communications makes good work habits and familiarity with the communication tools necessary. The good work habits must include personal accountability and the ability to schedule dynamically across multiple projects.

Project Control

The essentials here include progress reporting, managing expectations and quality control. In our example, there were no formal written project status reports. Progress was monitored as interim deliverables were shared with the client. A simple email update was sent to the sponsors to give them the sense of progress and the degree to which the client was accepting interim results.

Each member of the consulting team kept track of hours of effort by date and task. The account manager was to monitor cost data against the original budget. This did not happen formally. However, subjective evaluation by the principle performers on the consulting team made it clear that cost overrun was occurring.

Schedule compliance was managed in a very flexible and informal way. Given the fact that performers were multitasking, the choice was to have a very rigid schedule that allowed for definitive scheduling of work time or to leave the detailed schedule fluid and monitor against interim delivery dates. The team realized that definitive work schedules would not work. This led to the need to juggle individual schedules and to change interim delivery dates ad hoc. Because the client was flexible and the account manager and lead consultant managed expectations, this was not a problem.

However, internal to the consulting team, the need for realistic short term schedules and better personal planning was identified. One team member consistently over estimated his availability and his ability to do complex writing and analysis tasks. This led to missed internal delivery dates and the need for other team members to continuously adjust their schedules and roles.

Note that the absence of a definitive schedule was not a critical issue. Rather, it was the misestimating of short-term tasks resulting in cutting corners.

Change Control

The most controversial aspect of this project was scope change management and its impact on cost and schedule changes. During the project, it became clear that a critique of the plan was not really what the client needed, though it is what they had said they wanted. They needed a revised high-level structure for the model and better descriptions of the high level elements. This required additional effort on the part of the consulting team and a shift in focus from critique to creative. The roles of key consulting team members had to change on the fly to accommodate changed deliverables and the scheduling issues mentioned above.

While the project deadline was not exceptionally tight, it was constrained by an expected senior management review of the model to kick off of the client’s program. Formal change request and external approval of the change(s) would have jeopardized making the deadline and the client/vendor relationship. It was agreed that the project would be allowed to “morph” naturally as the client’s awareness of the real need evolved.

The result was a cost overrun (35 person days vs. a planned 19 days) and internal schedule changes. The client was exceptionally satisfied with the result and with the flexibility of the consulting team. The client’s deadline was met with a result that enabled a much more effective presentation to senior management and a far stronger platform for moving forward with their program.

The cost overrun was significant as a percentage of the estimate but in the context of the overall relationship with the client the overrun was not as significant. It was the account manager’s and her management’s call to address the overrun with the client after the fact.

Quality Control

Internal quality control was integrated into work sessions at which the consulting team interactively created and vetted interim deliverables. It was decided that an assembly line method for handling quality issues was not appropriate given the scheduling challenges and the need to collaborate among the subject matter experts. Internal work sessions were held to simultaneously come to a consensus about content and to correct defects on the fly. This approach is controversial. Some observers felt that the team spent too much time in synchronous meetings. The team felt that this was the only rational way to operate and that in the end it was what enabled a high quality result given the time frame and the working conditions.

Quality control by the client was handled in a more linear way with client team members individually reviewing deliverables and then working with the lead consultant both individually and in group sessions to address issues.

Lessons Learned

Among the lessons learned in this project were:

  • While an initial plan based on an agreed upon statement of work is essential, it is equally essential to be flexible so as to accommodate the evolving needs of the client and team members.
  • Informal status monitoring works well when the team is relatively small and there are frequent meaningful interim deliverables. Deliverables and their acceptance are the principle measures of progress.
  • Detailed schedules were not only unnecessary but would have frustrated and held up the team. Realistic short term delivery targets and extreme flexibility on the part of performers is needed. A flexible milestone level plan is needed as a frame work.
  • Cost control is essential in vendor/client projects. In internal projects, it is very desirable. Regular accounting and projection of the end cost is necessary to manage expectations and support decision making.
  • Change control is always necessary, but formality can get in the way of meeting the projects real objective – satisfying the client’s business needs. With a degree of cost control, it is possible to manage scope change cost issues after the fact. Agreement regarding the degree of formality among the principle stakeholders is absolutely necessary.
  • An assessment of the stability of the scope at the very beginning as part of risk analysis enables better cost estimating. This is difficult when the client’s objectives are rational and clearly stated.
  • Quality control can be merged into the development of deliverables (e.g., reports, plans, models, designs) using interactive work sessions. External review and acceptance are necessary.
  • Merging quality control with development activities and progress reporting with the acceptance of interim deliverables requires a very close relationship between project subject matter and performance team members and the project manager. The more the project manager is an active member the more easily this is done.
  • When the project manager is also a key performer, the PM must be constantly aware of the two hats he wears and when to wear one vs. the other. It is easy to lose focus of the project and its management when immersed in the work itself.
  • Administrative support and document production and management are very important and economical.

Organization Culture and Maturity

Organizational culture and maturity plus the ability to consciously manage change are critical factors to adapt lean agility.

Some environments have dysfunctional lean agility. Without a degree of PM maturity, the Lean part may cut away too much and the agility may get so that all control goes out the window. Maturity brings with it an appreciation for the value of formality and an infrastructure that promotes consistency, ensures effective portfolio management and supports PM capability development.

At the same time maturity without lean agility is not possible. Maturity includes what Dr Harold Kerzner refers to as “informal project management”. The mature organization continuously improves its process to minimize paper work and bureaucracy while doing due diligence regarding planning and control. Maturity is founded on the ability to apply the right degree of discipline, rigor and formality to each project according to situational needs.

But there is a tendency towards “maturity” without agility. People may misinterpret maturity and create restrictive, inflexible methodologies in the attempt to promote repeatability. The PMO becomes the compliance police. Project managers find “work arounds” to get their projects done, or, worse, they follow the standard, degrade performance and waste time and money.

Going lean and agile needs a managed change program with a charter, plan and all the other attributes of a well run program.

PMO attitudes must be assessed to make sure that all the attributes of a healthy, highly effective project management environment are valued and considered. The attributes of formality, repeatability, and objective performance evaluation must be balanced with the attributes of lean and agile performance including adaptability to the needs of each situation. The objective of maximizing project level autonomy with post project assessment should be recognized.

Motivation and Empowerment through Communication

Motivating stakeholders to strike the right balance among discipline, planning, control, consistency and flexibility is a critical element. It reduces the need for intrusive compliance monitoring and reduces the risk that people will blindly follow a process that is not right for their project.

Education is needed. Members of the organization at all levels must understand the business case for a lean/agile approach and their personal responsibility for implementing it. It is necessary to continuously reinforce the message through communities of practice, post project reviews and just in time knowledge about best practices, available templates and project examples.

Acknowledge the benefits of “violating” standards when the violation is needed to meet objectives. Provide a variance procedure that is quick, easy and rational.

Hold people accountable for complying with standards. Publish a project management practice policy. This is a statement of how project teams are expected to behave regarding compliance to standards and procedures and the use of common tools and terminology.

Remind project performers that it is not enough to just get the project done. Standards and procedures enable senior management and others to control the environment with its multiple projects and comply with external regulatory requirements. Compliance management, with accountability, is the means to ensure that standards and procedure are not ignored.

Project Type Taxonomy and Adaptability

To manage project diversity the organization needs taxonomy of project types. It categorizes projects based on attributes like domain (e.g., software development, R&D, HR, etc.), criticality, size in terms of cost, effort, number of participants, duration, complexity (e.g., global scope, number of participating groups, vendor involvement, etc.), risk, regulatory involvement, team performance experience, etc.

This sets the stage for conscious decision making regarding just how lean and agile the approach should be for each type of project. A large complex project with regulatory requirements has a different need for formal documentation and reporting than a small unregulated project performed by a highly cohesive team of professionals with good work habits for a single local client.

One approach does not fit all understanding this is an essential starting point for project management effectiveness.

Publish a Methodology

Publish a project management methodology that highlights adaptability. Include criteria for categorizing projects, alternative pathways for each category with templates, checklists, examples, best practice guidelines and easy access to tutorials on PM practices.

Insure that the people who are creating standards and methodologies and monitoring compliance are reminded of the need for flexibility and continuous refinement as well. Periodically have their work evaluated by project managers and performers and evaluate overall organizational performance improvement.

In general, project teams promote flexibility, minimal paper work and external control. They are focused on performing individual projects. The PMO promotes consistency and control for the sake of managing portfolios of projects and programs across time. They balance one another if there are proper checks and balances.

Conclusion

The goal of project management is to improve the probability of project success while minimizing cost and enabling control across multiple projects in the organization. To achieve this it is necessary to eliminate wasted effort and promote flexibility with the right balance between formality and informality, based on the needs of projects and their environment. A lean agile approach enables the organization to achieve this goal.

Achieving a dynamic, continuously improving organization requires managed change.

Agile Alliance (no date) retrieved on June 9, 2006 from www.agilealliance.org

Beck, K. & Fowler, M. (2001) Planning Extreme Programming. New Jersey: Addison-Wesley

Brainy Quotes (no date) “doing the same thing over and over again and expecting different results” retrieved on June 7, 2006 from http://www.brainyquote.com/quotes/authors/a/albert_einstein.html

DeCarlo, D. (2004) Extreme Project Management. San Francisco, CA: Jossey-Bass

Industry Forum (no date), Value Stream retrieved on June 7, 2006 from www.industryforum.co.uk/glossary.htm

Kerzner, H. (2001) Strategic Planning for Project management using a Project Management Maturity Model. New York, NY: John Wiley & Sons.

McBreen, P. (2003) Questioning Extreme Programming. New Jersey: Pearson Education Inc.

MIT Sloan (no date) Agile retrieved on June 9, 2006 from ccs.mit.edu/21c/iokey.html

Pitagorsky, G. (Fall of 2006) The Zen of Project Management. New York, NY: To be published by IIL Publishing (Chapter 9)

Pitagorsky, G. (September 2005) The Zen of PM: Agility and the Balance between Formality and Flexibility [Electronic Version] retrieved on June 12, 2006 from http://www.allpm.com/modules.php?op=modload&name=News&file=article&sid=1437&mode=hread&order=0&thold=0

Womack, J. & Jones, D. (1996) Lean Thinking: Banish Waste and Create Wealth in Your Corporation. New York, NY: Simon & Schuster

Wordnet (no date) Agile definition paragraph 1 retrieved on June 7, 2006 from http://wordnet.princeton.edu/perl/webwn?s=agile

Wordnet (no date) Agile definition paragraph 2 retrieved on June 7, 2006 from http://wordnet.princeton.edu/perl/webwn?s=agile

Wikipedia (no date) Lean Manufacturing retrieved on June 7, 2006 from http://en.wikipedia.org/wiki/Lean_manufacturing

Wysocki, R K. (2003) Effective Project Management. Indianapolis, IN: Wiley Publishing Inc.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2006, George Pitagorsky
Originally published as a part of 2006 PMI Global Congress Proceedings – Seattle Washington

Advertisement

Advertisement

Related Content

  • PM Network

    Tame the Haters member content locked

    By Fewell, Jesse "We want to be controversial for a moment and propose an end to projects and project management." So goes the opening chapter of #Noprojects: A Culture of Continuous Value, a book published this…

  • PM Network

    Degrees of Uncertainty registered user content locked

    By Fewell, Jesse If you've never heard project managers debate the merits of agile, here's a quick summary. A gruff project manager says, "Since your agile approach doesn't fit my oil exploration projects, it's not…

  • PM Network

    Don't Be Alarmed registered user content locked

    By Fewell, Jesse At a recent PMI networking meeting, someone asked me: "Now that the PMBOK® Guide has 'gone agile,' should those of us leading non-agile projects suddenly change course?" Tension filled the room. The…

  • PM Network

    Across The Spectrum registered user content locked

    By Rockwood, Kate For years, Michael Thompson, PMP, brushed off suggestions from other project professionals that he try agile approaches. "I was a hardcore waterfall guy for a long time and just not interested,"…

  • Project Management Journal

    Agile Methods on Large Projects in Large Organizations member content locked

    By Hobbs, Brian | Petit, Yvan Agile methods have taken software development by storm but have been primarily applied to projects in what is referred to as the "agile sweet spot," which consists of small collocated teams working…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.