Project Design for an Agile Workplace

Approaching the Agile Workplace

They were saying it 20 years ago, and it is more true today than it was then, “The only thing that is constant is change, and the rate of change is accelerating.” Some of the changes we have seen since the 1990’s include:


  • Software-as-a-Service
  • Agile Development
  • Remote/Distributed Workforce
  • Reorganizations too numerous to count

All of these changes are leading to the Agile Workplace, a working environment that can quickly transition in response to the needs of the market. We are not there yet, as there are still too many vestiges of hierarchical infrastructure, top-down command and control, and ego driven agendas within most organizations.

One element that is embedded in most organizations today that does support the shift to an agile workplace is the project centric approach to work. Essentially every organization in existence operates with a project mentality in one aspect or another. Projects done well can enable rapid change, but projects done poorly are merely extensions of the burdensome bureaucracies that sidetrack innovation and deflate effective operations. So the question becomes, how do we design projects that support the agile workplace?

Project Design is about Process

Project management is first and foremost about communication, making sure that the right person has the right information at the right time. The difficult part is being able to identify:

  • Who is the right person?
  • What is the right information?
  • When is the right time?

And to compound the situation, no single person ever knows the answer to all of these questions. The most common approach to alleviating this problem is to gather all the information into a project charter and project plan, and make it available to the project team. But then other questions arise, where did that information come from, did all stakeholders have input, is it current? Too often assumptions are made that lead to problems downstream. For example: a project manager may assume that the project sponsor queried all the stakeholders prior to generating the project mandate. Or the project team may assume that the root problem identified has been tied to a prioritized business need.

Explicit and open statements should drive the project forward, not assumptions. Similarly the process for generating project information needs to be open, and subject to feedback from all stakeholders.

In order for project information to be effective, not only must the content be readily accessible, but also the process and context behind the content must be transparent. When all the information about a project is available and everyone can see the roadmap for how that information was generated, only then do you have the basis for an agile project and thereby an agile workplace.

The bottom line is that the success of a project is dependent on the way you design the systems and processes that support the project.