Project and Programme Management

Agile from the Professional Services Perspective

Posted on by holnor

IMG_2574

Recently I was asked whether Agile is a viable proposition for Professional Service Organisations (PSO) to use in the management of projects? If so, what factors need to be taken into account?

Before answering this, it’s important to note that while Agile is a framework for Software Delivery, it is not a project managment methodology. This is a common misunderstanding. It is crucial to understand this when dealing with multi-discipline and multi-team projects.

In Scrum, (an Agile approach) an ideal team is made up of between 6 and 8 co-located members, all focused on the delivery of a product. If that product is independent of all other products then Agile is sufficiently structured to act as a quasi project management methodology. However, for all other types of project it is insufficient. Agile ignores all of those project management tasks required to ensure each team is working in a manner that supports and facilitates the work of the other dependent teams. It also ignores all those activities such as business case development, status reporting and change management that, while not delivery tasks per se, can be the difference between project success and failure.

That said, it is still true that from the perspective of a PSO Agile is the optimal mode of solution delivery. It allows for certainty in the engagement; as the customer is actively involved on a daily basis. It significantly reduces the gaps in engagement. For example, where the solution is handed over for UAT and the team waits for feedback before being able to finish. This in turn allows for greater resource utilisation and this means each project is potentially more profitable.

So why don’t all PSO’s use Agile all the time? Simple – often the customer can’t or won’t commit to the level of engagement required. You know the story, the key people needed to make decisions and sign off on the solution all have day jobs which prevent them from being available when they need to be. This means that the project stalls, or worse yet, takes the wrong direction when working on an ambiguous requirement. This is the typical scenario when dealing with smaller customers in particular.

An additional complication to the above comes with the customer’s lack of an internal IT function. Why is this a problem? Well, it prevents a project being truly Agile, as they will not have the capacity to automate the delivery of the solution into production (i.e. continuous integration/continuous delivery – CICD). CICD is a mandatory element of Agile projects which is often overlooked. Furthermore, if you don’t do it, then you aren’t truly Agile.

The PSO can set up CICD to deliver into an interim environment (usually a test environment); then manually release into production. This is a hybrid solution that will allow development to continue while the customer tests what has been delivered. Of course, in smaller projects the CICD overhead just isn’t worth it, as end to end the project is only going to be 1 or 2 sprints in duration (2-8 weeks). That is unless the customer wants to become Agile. In that case, setting up the automation mechanism becomes a proejct in its own right.

One other obstacle for a PSO using Agile to deliver a project is the contract itself. Many customers will view the initial statement of work as being a fixed price, no matter how you word it. The result is a rigidity in the project that prevents the team reacting to change in the way that Agile promotes. The change process has to be formal out of necessity for the PSO. It is the only way that a PSO can hold the customer to account for spurious changes, delays and the resulting cost overruns.

 

 

Agile in Mixed/Outsourced Environments

Posted on by holnor

IMG_2312

In 2011 I wrote a dissertation on Agile and outsourcing. After analysing all of the data I had collected along side that publicly available from various sources including Microsoft, Ambysoft (http://www.ambysoft.com/surveys/) and The Agile Alliance the only conclusion I could reach is that Agile and Outsourcing were incompatible. The fundamental obstacle was the contract between the vendor and the client.

Things have come a long way since then and it is possible to run projects in an agile manner. But only if the client understands the level of commitment required on their part. Having been on both sides of the contract I am finding that there is still a disconnect here. Often the expectation is that an Agile project can be run with the same level of customer engagement as a project run under a waterfall methodology, with a greater degree of success.

I exclude body shop engagements from the above as in those cases the reality is that the customer isn’t paying for the delivery of a project they are paying for the use of a specific type of resource/expertise.

So when are outsourced Agile projects successful? When the vendor is responsible for the delivery of the solution and has full commitment from the customer to be available at the agreed level. It all lies in the structure of the contract. The contract needs to be balanced and clear about the responsibilities of both parties and state the consequences from a delivery perspective if any of those responsibilities are not met.

Agile also does not work under a fixed price contract as the core tenet of Agile is the ability to deal with change. and fixed price is the antithesis of change.

Failure to acknowledge any of this is a recipe for disaster.

 

 

Embracing Creative Destruction to Get Ahead

Posted on by holnor

IMG_3023.jpg

In this recent post by Rohan Rajiv are some novel insights into what traditional companies need to do to get ahead of their rivals. While his focus is on the technology sector and how to compete against the big tech companies the lessons are valid for all. In particular the idea that the innovation curve is no longer contiguous.

The idea that innovation has jumped ahead and that there is a chasm between the market leaders and the traditionally solid performers should resonate no matter what industry you are in. It is just more evident in technology.

So, how does Rohan suggest that this chasm be bridged? By accepting that many of the tried and tested ideas that have made us reasonably sucessful will no longer to continue to bring success. Once this is understood it is easier to identify novel ways of challenging the status quo. Not all of them will work but those that do will accelerate business success. If a company takes a learn fast approach (see my earlier post for more on this idea) then the ideas that don’t work will encourage a culture of entreprenuerism within the company that will further accelerate success.

Over the years I have worked with a number of non-tech companies on transformation projects. The most successful of thes have seen the internal conversations revolove around how to manage the transition away from the traditional business model (e.g. we sell data products) to a new paradigm where the company is selling a technology based and data driven partnership with the customer.

Rohan’s over arching theme of “creative destruction” is one that the top tech firms have embraced wholeheartedly. For example Microsoft have stopped being Windows centric in the development of its productivity suite with updates oten being provided to other plattforms (iOS in particular) first. The idea is that they want a piece of every device out there. This is a variation of what Amazon has done with it’s market place. They want a piece of every online transaction and don’t care if they sell the product or someone else does.

Applying creative destruction in our professional and personal lives is not something that comes easy. However, if we are realistic, the days of a person holding a job for life are long gone and  there will be times in which it is essential for us to reinvent ourselves in order to stay relevant within constantly evolving industries.

A classic example of this is traditional manufacturing in western countries. Repetitive low skill jobs are either been performed by robots or have been moved off shore to countries with cheaper labour rates. The remaining manufacturing jobs are high tech and higly skilled. The result is a significant jump in unemployment while people retrain or find alternative low paid work (if it exists).

So no matter who we are and what we do, unless we embrace change we will find it increasingly difficult to keep up. Or as Rohan sums up “what got us here won’t get us there.”

 

BBC DMI failure

Posted on by holnor

The failure of the BBC’s DMI programme is a prime example of why it is so important for senior IT management to insist on having fully engaged, committed and responsible business stakeholders. If that isn’t happening then the programme manager / CTO needs to put the programme on hold until the right people are involved from the business.

http://www.cio.co.uk/blogs/editor-in-chief/bbc-trust-board-must-accept-blame-in-digital-archive-disaster/

The Agile Project Manager – Does it exist

Posted on by holnor

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

  1. help the project accept and adapt to change
  2. 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…

Lessons Learned – not a one off activity

Posted on by holnor

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:

  1. prevent poor behaviour recurring
  2. identify good behaviour and encourage it to be repeated
  3. capture key business drivers that have been highlighted by any issues that have arisen
  4. 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.

Communication – a lesson I learned in Starbucks of all places

Posted on by holnor

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?

The Trouble with Metrics

Posted on by holnor

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):

  1. is the metric relevant (to the job and/or system)
  2. what behaviour is use of the metric likely to encourage (and is that what you want to happen)
  3. is the information the metric conveys actionable
  4. 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.

Project (Outputs) v Programme Management (Outcomes)

Posted on by holnor

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.

BYOD – Just the tablet/smartphone or should it be something more

Posted on by holnor

With all the talk and hype around BYOD(Bring Your Own Device) the focus is squarely on the hardware and primarily tablet and smart phones. But what about other devices, a mouse, keyboard, a laptop or indeed the software that you need or use to make yourself more productive? Is it the responsibility of your employer to provide it? Or do you like to use your own?

Personally I like my employer to provide the basics, a desk, chair, phone and laptop (if they have a locked down environment) with the essential productivity tools of the PM trade (Word, Excel, PowerPoint and Project) and Email. Beyond that all I ask is that they allow or facilitate the installation of other tools that I have a valid licence for or an open source equivalent.

This comes from a lesson learned way back when I was a junior code monkey (thats a programmer for those of you that aren’t from an IT background). I worked with a contractor who seemed to be able to do things in hours that would take the rest of us days or even weeks. I cornered him at a post release celebration one night and asked him how he did it. His tip… If you know of something out there that will make you more productive use it. it doesn’t matter if its a better mouse, keyboard or a piece of utility software. Even if you have to pay for it yourself it’s worth it in the long run. Think of them like a builder thinks of his tools. A good tradesman will use the best tools he can afford as that allows him to work quickly and efficiently, maximising the amount of work he can do and therefore money he can earn. Would you want a builder to use the cheapest tools he can find? Or would you prefer that he use precision tools that are robust and reliable? Having a retired builder for a father I knew he was right.

Since then I have built up a software library that I look to leverage to what ever extent my employer/ client will permit. Some have an aversion to the use of 3rd party tools in their development or to installing open source software within their environment. But thanks to the BYOD phenomena, these days more and more are opening up to the idea and realising that productivity is what’s matters most.

These days my productivity kit bag includes an iPad, mouse, phone, various portable storage devices and cloud based services such as Office 365 and GoTo Meeting. This kit is evolving and as I find new, better and (sometimes) cheaper ways to do things I will replace the older less productive tools. This may be a mindset difference between the contractor and the permanent employee but I truly believe that I have a responsibility to my employer to be as productive as possible.

So far this is a philosophy that has has served me well with every contract being extended past the initial engagement.