Search This Blog


25 September 2013

Kelsey on "What does project management mean to me?" #PMFlashBlog

An open letter to project managers

Dear Project Managers

Firstly, this is not a sermon, I'm not a follower of any particular system of religious belief, what I say is not grounded in any theology, but is an open letter, based on my own epistemologically empiricist view of the world. Secondly, I am not a project manager; my business card and CV suggest that my discipline is business analysis, so I will begin by setting out the background material that has informed this post.  To provide some context, after a quick count up, I have worked on (roughly) 30 software development projects over 20 or so years. Mostly my role has been business analyst, these days team member is the best description. I have often needed to perform duties that could be described as project management, but I have never worn your hat or walked in your shoes. I have, however, had the opportunity to work closely with quite a few of you over the years, so it is from this perspective that this post is written. 

My background as a business analyst could best be described as traditional and formal. I cut my BA teeth on, business requirements specifications, functional specifications and traceability matrices. My place in the software project world was defined by a line, (or several) on your Gantt chart and my definition of done, was met when 100 percent complete and a milestone due date coincided. Then I was off your project and ready to meet my next PM and do it all again. In the meantime, perfect software would be churned out by a development team, tested by a QA team and delivered as a fait a complet to delighted customers. 

This scenario assumes that the business is able (in advance) to accurately define the right functionality for a given product, such that the time and resources required to develop this functionality can be specified. Further, it is assumed that it is possible to accurately record this information in a plan and track progress against that plan. This leads to the underlying premise of project management, that the effort required to deliver a project is reliably estimable regardless of the product or service to be delivered.

The result of the assumptions described above is that software development project manager has an unenviable task. The essay, The Tower of Babel Did Not Fail (Adamczyk & Hafiz, 2010) discusses the challenges associated with attempting to succeed at something, which (historical evidence suggests (Larman & Basili, 2003) has around a 70% chance of failure. This essay argues that software development projects are distinctly different to civil engineering projects in several fundamental ways. Some of the key differences are that there are few known or fixed variables, such as the strength of materials or the impact of gravity and that much of what is developed is completely novel to those developing it. In particular, software products are expected to be modifiable, scalable and reliable, (over an unspecified period of time) regardless of the domain and environment in which they are asked to operate.

In response to the challenges described above, the development of iterative and incremental approaches to software development (Larman & Basili, 2003)and the development of formal software development governance (SDG) models (Bannerman, 2009) have been credited with some modest improvements to the dismal success rates of software development projects. More recently however, in his discussion of the 2012 Standish, CHAOS report ("The Standish Group," 2013) Mike Cohn, claims that use of Agile methodologies (rather than those classed as iterative and incremental) offer even greater advantages, with reported success rates for Agile software development projects of up to 42% (Cohn, 2013). This has led to an increasing number of organisations experimenting with or formally adopting Agile approaches to the implementation of software development projects. Particularly in the last 3 years, Agile approaches, tools and techniques have made their way, to some extent or another, into just about every software development project, commercial or otherwise. If you haven’t come across it yet, it is probable that you will.  

If your discipline happens to be software development, you are well served; much of the discussion around Agile has been focused on the actual process of designing, coding and testing software, that’s where most adoptions start and where there is the most expertise. However, if your discipline is business analysis or project management the story is different. Not only is your role not described in the Agile manifesto, there are no practices to support it either. This means, that for those of us who find ourselves working on a project using scrum, Kanban, XP or one of many other Agile methodologies we need to reinvent and rethink our role. Having been a little way down this road now, one of the key lessons for me has been that as a member of an Agile team I  value different things from my colleagues than I did before and that I have different expectations of my project manager. 

Whilst the set of principles and values, which underlie Agile, are simple, fully adopting them is not. This is because Agile is much more than a set of practices; it is a philosophical lens, through which to see and think about the work we do. Making the shift from the thinking style required by plan based approaches to project management to Agile, change driven, approaches has a far greater impact on the success of otherwise of Agile project than the adoption of a daily standup. This is where the strengths and skill set of the software project manager can really make a difference if you do the following things;

  •       Learn about Agile, by this I mean, get to know the underlying philosophical theory and support your team in their attempts to internalise it. Understand that Agile requires more discipline and more rigor than a traditional approach primarily because it demands transparency and accountability. You actually have to produce some software at the end of each iteration/sprint; you really cannot ship a document.   
  •       Hire an Agile coach, listen to them and let them do their job, which is to help the team to become high performing and self organising. This will mean that at a minimum you can stop spending your time trying to manage other people's (developers/testers/BA's) time.  
  •  Understand the purpose of each practice, respect it, and use your skills to facilitate the team's ability to apply their practices, You can only gain from doing this, for example attending the daily standup (in a scrum team) or facilitating the use of a shared information radiator means you will have a far better understanding of exactly where your project is at.  
  •      Teach the business about Agile, if this is their first Agile project, they will see it as inherently risky. Understand that the business has probably learned to take comfort from a progress marker on a Gantt chart and will take time to understand that a demonstration of working software is actually more useful as a measure of progress.
  •       Think about how you can serve the team by removing obstacles and bottlenecks; resourcing to support concepts like continuous integration and automated testing, reduce your risk significantly.
  • Hire intelligently, think about your team as a complex adaptive system, new resources need to either understand Agile or be willing to develop their understanding of Agile. 
  •   Ferociously protect your constraints, if for example you have a team member with a critical skill set, do not allow that person to be pulled in a million and one directions as every project's goto girl/guy. 
  •      Have a shared, respected and immutable definition of done 
  •    Be prepared to roll up your sleeves and pitch in, Agile teams do not have demarcation disputes.

There are a couple of important don'ts

  •       Don't hijack, or allow someone else to hijack a sprint and then complain when the team does not meet it's commitment.
  •       Don't tolerate an individual who undermines what the team is trying to achieve, no matter how senior ("special") they are.
  •      Don't attempt to use team velocity as a measure of performance or a comparison between teams .

As a project manager on an Agile software development project, your job is not command and control, but is truly that of the servant leader, you play a key role as a facilitator between the team and business and are an integral enabler of the team's success. If you are lucky you will be able to keep a team together over a long project or over multiple projects; when you have sprinted 20 or 30 times with the same group of people, you develop a sense of community, commitment and mutual respect which transcends the mundane and makes the process and the product better for everyone.

Yours sincerely

The business analyst  


Adamczyk, P., & Hafiz, M. (2010). The Tower of Babel did not fail. Paper presented at the Proceedings of the ACM international conference on Object oriented programming systems languages and applications, Reno/Tahoe, Nevada, USA

Bannerman, P. L. (2009, 17-17 May 2009). Software development governance: A meta-management perspective. Paper presented at the Software Development Governance, 2009. SDG '09. ICSE Workshop on.

Cohn, M. (2013). Mountain Goat Software.   Retrieved 23/05, 2013, from

Larman, C., & Basili, V. R. (2003). Iterative and incremental developments. a brief history. Computer, 36(6), 47-56. doi: 10.1109/mc.2003.1204375

The Standish Group. (2013).   Retrieved 03/06/2013, 2013, from