Why are the likes of Amazon, Apple and Google successful and seemingly able to continually re-invent themselves? Design Thinking (i.e. thinking like a designer) may, in part, explain it.
The other part of their success is the focus on customer interaction and ensuring that this is immediate, relevant and provides an outcome or resolution for both the customer and the organisation. Those less successful tend to focus on the outcome for the organisation only.
Combining a customer focus with design thinking and you end up with very creative ways of resolving customer issues or developing new products…
This article from Management Today gives some interesting examples and expands on Design Thinking:
Taking this approach as a Project Manager, a developer or an administrator could result in some novel outcomes for your projects and deliver game changing results for your client / employer.
Recently I attended a seminar on “Agile” software development. One of the statements made by the presenter was to the effect that once agile is implemented properly an organisation will quickly realise that they don’t need project managers. The reason… the close, frequent interaction between the business and developers means that the management of a project is handled almost as a by product.
I’m not convinced by this thinking, unless it is restricted to the simple case of a small project with a fully committed and engaged product owner. In more complex situations (e.g. Multiple agile development teams working on a project in parallel) someone is needed to keep everything lines up and remains on track. Sounds like a project manager (PM) to me…
So in this situation, what makes a Project Manager an Agile one? How can you recognise one? First and foremost an agile project manager will be able to facilitate two competing needs
- help the project accept and adapt to change
- prevent change impacting the project delivery
This is the challenge in agile, where it is possible to do everything the client asks but not everything they ask for should be done. If you only have a product owner and the scrum master then in complex environments the former is likely and without the checks and balances that a disciplined project manager brings to the table then projects will fail.
I do believe the nature of project management will change. With more and more projects being delivered using agile or lean methodologies it has to. The focus for a project manager will become ensuring the delivery of the right thing at the right time whether that is requirements, designs, code or a functioning product. This is essential when the paradigm is iterative.
Project managers will live and breathe the mantra “if you don’t need it now… it can wait” and every will focus on Just In Time delivery. Or it will once vendors and customers figure out how to work effectively together using agile…
So many times I have been involved in projects where once the solution has been delivered a project manager, sponsor or vendor will say “now we need to review the project and record the lessons learned”. The idea being that the lessons can then be used to ensure those mistakes aren’t repeated, or that things that really worked well can be replicated on subsequent projects.
Sounds good, right? Wrong! Why should the next project be the beneficiary of your hard won lessons? A lessons learned log should be maintained throughout the life of a project. The log should be reviewed and discussed within the team regularly and include stakeholders or their representatives from the business. That way you can:
- prevent poor behaviour recurring
- identify good behaviour and encourage it to be repeated
- capture key business drivers that have been highlighted by any issues that have arisen
- highlight areas of conflict between business areas (e.g. Sales v marketing) and the best mechanism(s) for resolving the conflict.
By doing this throughout the life of a project, the project becomes self correcting as those individual experiences are shared with the team. This reenforces behaviours, establishes trust within the team and with the business and ultimately helps improve the chances for the successful delivery of the project. At the end of the day delivery is what it’s all about.
Sitting I Starbucks a Saturday or so ago having a quiet coffee and reading the paper. It was the last place I was expecting to learn this lesson. A group of 6 young kids (ages ranging from about 4 to 6) and their mothers came in to the store, pushing and shoving and generally having fun as kids do. The striking thing about this group though is that every single person had a hearing impairment including the adults.
The thing that struck me was that if they wanted to “talk” to someone they had to establish eye contact. Because of this everyone paid attention to each other and the conversations were clear and concise. There were no misunderstandings in regard to what was expected, what each of them wanted or indeed how they felt.
In this day and age where communication is becoming more and more remote with less and less face to face interaction it made me sit up and take notice. I’ve lost count of the times over the last 6 months where email or IM communications have spiralled out of control over a subject or situation that could have, should have and ultimately were resolved by having a 5 minute face to face conversation.
There is a clarity of purpose and intent that can be conveyed in a look or the tone of the voice that is absent in written material. Without this the effort needed to gain the same clarity goes up exponentially with the complexity of the subject.
So next time you find yourself on your third email explanation of something “simple” maybe it’s time to pick up the phone, or better yet get up and go talk to them?
When talking to people about data related projects I have started noticing that it doesn’t take long to get on to the topic of Big Data. It’s a subject that is getting a lot of press at the moment so that’s not too surprising.
The thing that I am finding surprising is that few of those I have been talking to make the connection between Big Data and Data Visualisation. To them the talk is all about the “Three V’s” (Velocity, Variety and Volume) that define big data. My question, once we have covered the ground of how do we cater for and handle the three V’s, is what about the fourth V, Visualisation?
From where I stand it’s all well and good being able to stuff data into a cleverly designed warehouse at an ever increasing rate. But what is the point in that if all you do is pull it out in static, flat one dimensional reports? To make the data really useful and come alive you really need to make it tell a story in a dynamic and visually appealing way. The message you are trying to convey should jump off the screen at the user and at the same time lead them to zero in on the the good AND the bad news.
These days there are an increasing number of tools that allow you to this with varying degrees of flexibility, complexity, functionality and naturally cost. All you have to do is think about how to make it easy for people to get at the information they need through the overwhelming volumes of data (to them) that is available.
Over the years I have worked on a number of back office system projects. Typically they projects are aimed at delivering either cost savings or performance improvements (or optimistically both). Naturally management are eager to monitor and calculate how much of each is achieved. To that end they look to set up a number of measurements that will show the level of uptake, throughput, cost per unit etc.
When the system is designed to make it easier for someone to do their job you would expect that their productivity would increase… Makes sense right? But it’s not alway the case. For example implementing a system that makes it easier for a sales rep to capture the client details, record conversations and track follow up actions will only increase the productivity of the rep if their job doesn’t require them to meet the client face to face. It would be pointless therefore trying to measure the benefit of the new system and the performance of the rep on the basis of the number of phone calls the rep makes each day. If you do then the result of that will be to encourage sales reps to sit at a desk and make phone calls. Not a good result when what you really want from them is to be generating new sales and building relationships with clients so that they become repeat customers.
Therein likes the problem with metrics… Get them right and they will be able to tell you a story of how your business is performing, identify areas for improvement and highlight those activities that are contributing to good performance. Get them wrong and they have the unintended consequence of influencing peoples behaviour toward irrelevant tasks that should not be their focus.
A classic example of this is the UK government target that no patient should wait more than 2 days to see a doctor. The result… When you ring up to make an appointment many doctors won’t allow you to make an appointment that is more than 2 days in the future as it will distort their statistics. Additionally if there are no appointments available you have to ring back the next day in order to make an appointment for 2 days in the future (rinse and repeat until you get in early enough to beat the rush). They do this as the government is not interested in how many people are unable to make an appointment on their first, second, third (or more) attempt. But I’m almost certain this was not the behaviour that the government was trying to encourage. It’s just the unintended consequence of a poorly thought out and defined metric.
So when determining what metrics should be used to measure performance, you must determine (either for yourself or your client/customer):
- is the metric relevant (to the job and/or system)
- what behaviour is use of the metric likely to encourage (and is that what you want to happen)
- is the information the metric conveys actionable
- what are you going to do with the information
If the answer to any of the above is negative then it’s probably not the right metric to be using. On the bright side though, being able to identify this will make you look good and help avoid some of the post implementation pitfalls that beset many projects.
Having a discussion a week or two back with the head of a PMO and the idea of whether I would like to take on a large project with great travel perks (e.g 2-3 trips to Australia next year). After some serious thought I had to turn it down. Why? I suddenly realised that I am no longer a Project Manager. Sure I still know how to manage projects and don’t think those skills ever go away. Actually I still use most of them daily. The difference is in my focus. It has been a gradual shift over a couple of years from output to outcome, from project to programme manager.
What do i mean by that? Well, as a project manager your focus is on the outputs of the project, the requirements, the designs and the end product being delivered to the client. This doesn’t change no matter what industry you work in. As a programme manager you don’t focus on those things. I’m not saying they aren’t important, they are. It’s just that its not the right focus for a programme manager.
A programme manager has to focus on the value that is being delivered to the client often through multiple interrelated (sometimes very loosely) projects. A project manager does not normally have the time to dedicate to the co-ordination of these projects and nor should they as it only distracts them from their job at hand.
A programme manager should also act as the first point of escalation for those things that can’t be resolved within the project, e.g. Resource contention between projects is quite frequently a blocker for a project that needs outside intervention to clear. If its between two projects in the same programme the programme manager can make the call. If the other project is outside of the programme then the programme manager can negotiate with the business to have the priority set and the impact (on time & cost) accepted or to argue the need for additional resource. This frees up the project manager to concentrate on delivering.
A programme manager will employ most of the skills used in project management, negotiation, planning, diplomacy and creativity (it’s not all about MS Project!) so a good grounding in project management is beneficial. However, as I said above a, programme is all about the value to the business and as such is not bound to a methodology. Indeed various methodologies can be employed within a single programme. It’s a case of what ever fits the project best, the only concern for the programme manager should be that the end product delivers the expected value to the business. The rest is down to the project manager.