Value, Flow and Quality

The PMI Announcement

As a result of the news that the PMI have endorsed Agile Project Management I was doing some reading around the topic and came across this article.  The question posed seems like a very traditional project management question because it is asked from the basis that everything is delivered at the end of a project.  It doesn’t consider that a scope could be wrong, or the times are impossible or the costs are not enough. This is what project managers are taught and this is one of the reasons that so many projects fail, in my opinion.  To be able to predict an arbitrary date sometime into the future that is months, years or decades away is a nonsense.  Predicting how much money you might spend or what the scope might be during that period seems even more impossible to my mind.  And when you finally throw in poorly managed engineering techniques which diminishes the quality, you are always left at the end increasing time, budgets and reducing the scope. Without having built up any knowledge as to whether your predictions might be accurate or not people are committing to the parameters of time, cost and scope (quality is always high at the beginning of any project when it is just a thought in someone’s head, but diminishes when the reality of building stuff actually kicks in which is why the commitment of any project doesn’t really consider quality).

I know this is quite a glum scenario, but there you are.  It is still the most common scenario that I see in environments where projects are the norm and commitments are made to be concrete on the back of an approved project. I think the fact that the project is really the only construct discussed by the project management community is what creates this thinking – the clue is in the title!  I remember saying to a client a couple of years back ‘I guarantee 100% that you will NOT get 100% of the things you are thinking of right now on the date in your project plan that is over 18 months away.   But, how about we work with a little more uncertainty and we aim to deliver 60% to 70% between this date and this date approximately 18 months away so that we can get something into the field for a real trial with real customers, and we would have already got feedback on what we have been doing at regular intervals beforehand.  Which one would you prefer?’  The debate that this created was interesting, because people started to say: ‘well, it would be good to get something to play with before the end date and something we could show our customers’. Others were still very much: ‘well, we have to deliver everything on the date’.  So, I simply asked: ‘what is everything?’.  Stunned silence followed.

I know many of you will have been in similar surreal conversations in your work too, but it always strikes me as a little… well, stupid.  The proliferation of the idea that complicated projects can be predicted so accurately is absurd.  The XP game has demonstrated many times to many teams that even the simplest tasks (like blowing up balloons) cannot be predicted accurately until we have a few goes at it. If we try the same project over and over again, I guarantee we will get good at that project.

You get what you think about

I have come across this saying a number of times: Watch your thoughts for they become your words. Watch your words for they become your actions. Watch your actions for they become your habits. Watch your habits for they become your character. See your character become your destiny. I don’t know who this should be attributed to, but I do like it. In this context, it brings to my mind the fact that the focus of the project management community is focusing on the wrong things.

I remember when I got my first real budget responsibility as an IT Director.  It was a very significant sum of money and one of my more mature and long-serving colleagues took me aside and said: ‘Phil, always hit your numbers. Never underspend or overspend your budgets. This is the most important aspect of your job.  Hit your numbers and you will be fine.’  The young, idealistic me was a little taken aback by this advice. I thought the point was to deliver the projects and programmes, but apparently I was mistaken. How naive.

For me, the focus on trading time, cost and scope off against one another is the wrong focus.  I think managers should be focusing on Value, Flow and Quality.  Each of these words require many more posts to do them justice, but my intention here is to say that the project managers (or any managers involved in delivering products, services, systems, projects, programmes etc) should focus on creating these three things in their organisations.  I am not arguing that cost control is unimportant.  It is important. But, it is ridiculous to believe that this is the most important thing.  The biggest ‘cost’ of a business is a failure to turn ideas into valuable products and services that meet or exceed the expectations of customers.  Going further, there is an implicit cost of not delivering quickly.  For every extra day a feature takes to be delivered a day has been lost reaping economic benefit for that feature. This is the Cost of Delay and managers need to understand this.

Value is not fluffy

One argument I have heard on numerous occasions is that it is difficult to really understand the value of an individual feature or activity, and that’s why we focus on cost. We know how to deal with costs. Value is difficult to measure. This makes no sense to me. If it does to anyone who reads this, please try to enlighten me. I do want to learn.

In the agile community the word value is used a lot. In fact, in my experience it is overused and abused to argue for the things that people want to do rather than things that have real value (i.e. money/economic benefit). I hear the cries now: ‘What about other value types such as happiness of employees?’. Happy people has an economic benefit. Heskett et al postulated a model called the Service Profit Chain that links employees, customers and quality into a profit model. The challenge is creating a value model that works for your business that allows you to trade off different features, requirements and improvements in what you intend to deliver and the way you intend to deliver them. Please remember that any model you create can be refined as you learn more about how that model is being used. You might not get it right first time, but you can definitely have a good debate with your finance director about how you trade things off for the highest economic return.

Projects are short-sighted

One of the problems with projects is that they are inherently short-sighted.  A project manager is judged on their ability to deliver the project, however they do that. It doesn’t matter what state they leave any underlying IT systems, product architectures or people who were working on the project. Managing the assets of a business with a view for the longer-term is a philosophy that is promoted in lean, and is an important principle to be instilled in managers and should be considered when designing any organisational structures and philosophies. When I see organisations that are set up solely around projects and not the underlying components and systems I get nervous.  If more than one project manager affects a common platform without any need to care about the quality they leave behind and the ability for the next project manager to be successful then there is an issue. Projects do not promote flow.  They should be used more sparingly than they are.

Quality is not negotiable

One of the strongest statements that has come out of the agile community is that Quality is not negotiable. As I mentioned in a previous post you need to demand technical excellence. However, as I mentioned previously, when people think about quality at the inception of a project it is easy to think that your project is going to be of the highest quality, but reality bites when you get going. It is easy to have standards about your engineering when you are in the throws of thrashing out your requirements and design in a traditional project. But, why do we believe spending our time on requirements and design at the beginning of a project is more valuable and important than spending time of creating the right environment for building high quality software? Quality and productivity are inextricably linked. Poor quality now will slow you down in the future. Great quality now will increase the flow of value and improve speed-to-market over the longer-term.

A virtuous circle

Time, cost and scope are often called the Iron Triangle.  It sounds like a very negative phrase.  I prefer to think about something that creates a virtuous cycle.  Value, Flow and Quality creates a virtuous circle. This does not mean you are challenging the laws of physics as the article mentioned at the beginning suggested, but it does change the mindset about how you can manage your product, service and IT deliveries. The idea is to go as fast as you can possibly go. Managing projects to time, cost and quality hasn’t given us the ability to go as fast as we can go. If the PMI’s announcement starts to educate project managers to start thinking this way, then I believe it is a really valuable move for our industry. Time for a change? I think so.