Breaking the Program Management Ice

Many project, program and portfolio managers face the challenge of introducing agile concepts and practices to a traditional organisation. This is the topic of many great blogs, including a series of posts by Dean Leffingwell on Enterprise Agility.

When I joined Atlassian I had the opposite problem. I was hired to do program management in a company that has been developing great software products in a relatively lean & agile way since its inception. There was some skepticism around the whole idea of program management - some people were worried (understandably) that it would mean more processes and an extra layer of management goo that would just slow everything down. On the other hand, there was a pretty clear need for something like program management, as the company was doing more and more cross-product development and someone needed to play the role of conductor.

Obviously, killing the agility by introducing a set of standard program management tools and processes would have been a bad choice. But some things had to be done differently, or I wouldn't have made it past probation. Luckily for me, there were a few obvious clues as to how I might, ever so carefully, proceed:

1. Atlassian runs on a wiki (Confluence, which we also make... end of today's plug)
2. Everyone who works at Atlassian is smart
3. Smart people tend to have well-considered opinions, which they are usually happy to share
4. I had read The First 90 Days when starting my last job, and remembered Michael Watkins' excellent advice about not making changes until you've done a lot of observing and listening.

These clues led me to an approach, which I'm still adjusting and refining, but which has so far not resulted in total disaster:

a) I manage all our programs with wiki pages, not offline documents. This is standard procedure for every function at Atlassian (Development, Product Management, Marketing, HR, IT, etc), and it works brilliantly for projects and programs. My program plans are visible to everyone in the company and are constantly updated, by me and others on the various project teams.

b) I ask for feedback from the people involved in my programs, to see where I can improve and what I could do differently. These guys have great ideas, and they're not shy about sharing them. (Note to self: could probably do another quick round of feedback this month).

c) I make the assumption that most people want the bigger picture (the program, in this case) to succeed. People operate within their own teams and projects day-to-day, and that is where their primary interest lies. But by making sure people know what the program goals are (and why), I generally find that they are willing to adjust their own project goals to get with the program, so to speak.

d) I try to grow & nurture relationships with the people participating in the program - the CEOs, product managers, project leads, architects, team members. I don't mean those insincere, distracted relationships. I mean actually getting to know individuals, helping them out when I can, and not forcefeeding them with my own agenda. This is the part I enjoy the most, and the fact that it leads to better program outcomes (often via point c above) is a bonus.

Well that was more high-level than I intended, but stay tuned. In future posts I'll talk more specifically about using wikis and other lightweight tools to manage programs in an agile way.