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. 

Asked and Answered

I have had a block lately. I can’t seem to find what to write about. I go through these phases where all the thoughts get jumbled up on top of each other and I think there is some connection to it all, I just can’t seem to pull it together. So today I just decided to start writing and see what comes out.

I have been catching up on my reading, though it took a while. It seems that when I get behind my newsreader and the Unread list grows, I avoid it, you know the viscious circle. Anyway I got caught up. I find that I am narrowing who I enjoy reading, and the others I am just cruzing through. The top of my list right now is Kathy Sierra at Creating Passionate Users, followed closely by Jory DesJardines at Pause.

Kathy put up a couple of posts recently, Don’t forget square one…, and How to be an expert, that have connected for me. Basically she says that to be great, you have to return to the basics on a regular basis to keep improving.

I am trying to tie that concept to "how do you improve an organization’s competence?". I am beginning to think that part of the problem is that it is hard to clearly define what an organization’s basic competencies are. I run into this often as a project manager. When a new project starts, everyone loves to jump in talking about solutions. In fact the project is often described in terms of its solution. What I usually find is that everyone is finding solutions to different problems, where the solution happens to look similar. In this case, getting back to basics may mean agreeing to what is the question.

Ask any project team what their objective is and odds are that their answer will be the description of a solution: "to build a bridge" or "to reduce our vendor cost". Neither of these responses provide any insight as to who this helps or why they might want it. Russel Ackoff refers to this distinction as the difference between efficiency vs effectiveness, in his book Re-Creating the Corporation.

I want to develop a set of basic questions that will help me work with my clients and allow them to more clearly see their own objectives. I will post my questions as I come up with them.