Adventures in home working » ProjectManagement

Conceptual integrity

Steve Richards — Sun, 14 Oct 2007 03:20:00 +0000

A long time ago now I read the Mythical Man Month, and I remember two things from it:

On a large activity conceptual integrity is really difficult to achieve and maintain
In the sixties IBM seemed to do a better job at managing large development programmes than we do now with all of our computer assistance

I’m often reminded of these two points, almost every day I see the evidence of an activity that has no conceptual integrity and even when it started with it, most programmes I deal with have lost it completely by the time they have finished. Joel illustrates the point nicely with this story:

In one of Gerald Weinberg’s books, probably The Secrets of Consulting, there’s the apocryphal story of the giant multinational hamburger chain where some bright MBA figured out that eliminating just three sesame seeds from a sesame-seed bun would be completely unnoticeable by anyone yet would save the company $126,000 per year. So they do it, and time passes, and another bushy-tailed MBA comes along, and does another study, and concludes that removing another five sesame seeds wouldn’t hurt either, and would save even more money, and so on and so forth, every year or two, the new management trainee looking for ways to save money proposes removing a sesame seed or two, until eventually, they’re shipping hamburger buns with exactly three sesame seeds artfully arranged in a triangle, and nobody buys their hamburgers any more.

and goes on to describe how he has been victim of this conceptual integrity drift himself, although it’s impressive that he realized that it had happened and stopped it, if this had been an activity run by a project manager and not an owner I bet it would never have been stopped!

This is sort of what happened with our new web design. We’ve been tweaking it and polishing it and changing things carefully, and the firm we hired to design it has been taking us step-by-step through information architecture, site maps, wireframes, initial designs, and several rounds of design. All with a carefully-designed process to get our buy-in at every step along the way. And so far every step I thought the design was converging and we’d get a nice web design out of it.

And then I came back after a week on the road, took one look at it, and thought, oh crap. We can’t go public with that.

So as I was saying – I’m also often reminded about the fact that we seem to have forgotten how to run programmes (and maybe projects as well), I partly blame computers – today’s projects seem to be way too much about sitting in from of a laptop producing plans, estimates, registers, and deliverables and not enough about objectives, people, progress, discussion, review and quality.

Joel has written a great book, that has some useful insights into these and many other issues.

The future of product management (2)

Steve Richards — Wed, 28 Mar 2007 00:34:00 +0000

Yesterday I posted some of my own ideas on improving product management. Today I thought I would share a few of the better articles I have read on the topic, and contrast them to my own ideas.

First up Kathy Sierra has a post on leveraging the community to to help build a more effective community around your products, its a good read and one of the topics she talks about is using the community to help with product design but she goes way beyond that. I am a real fan of building community, I’ve done it several times and every time I find we get much more back from the community than the investment we make, but best of all it really is a win win, because the community gets much more back in total than they invest as well. The thing I like most is that everything seems to get easier, rather than the sometimes difficult customer-supplier model it starts to feel much more like a real partnership and sometimes even like a team.

I have a few posts on the power of community, this one in particular

Next up the inspirational Ismael Ghalimi describes how he is using demand driven development, his approach is very simillar to the one I proposed, although he’s not using some of the market driven aspects that appealed to me. He restricts his scope to custom features, which is a great place to start:

The main idea behind Demand Driven Development is to syndicate the development of custom features among a group of customers who need the same features and are willing to pay for it. Here is how it works: customers get access to a detailed product roadmap and can suggest the addition of new features to it. Upon review by the vendor, features that make sense get added to the roadmap, but no delivery dates are committed for them. Instead, customers can bid for the development of specific features, indicating how much they are willing to pay for which feature, assuming that the feature could be delivered within a certain timeframe. Multiple customers can bid for the same feature, and once enough bids have been collected to fund its development, the vendor develops the feature and delivers it to the group of sponsors, three to six months before anybody else gets it.

Ismail has recently provided an update to his original post which he titled How To Outsource Product Management and it seems to be going very well. I liked this quote:

Product Management is one of the most critical functions for any enterprise software company. As a product gets used by more and more customers, requests for new features start to pile in, and the job of a Product Manager is to prioritize them in order to meet customers’ needs, while avoiding feature creep. During Intalio’s early years as a company, we found it very difficult to manage this process. Too many resources where allocated to the development of features that very few customers actually needed, while features that could have made a significant difference on the market did not get developed, for lack of available resources. We only managed to solve this problem when we decided to outsource it, and selected an unlikely outsourcing partner for it: our customers.

In Ismails approach, simillar to mine he has a number of phases:

identification, where an initial list of options is proposed, added to, discussed and rated, then they moves on to
estimating, where a specification is drafted, effort estimated and a rough cost is developed, then they moves on to
out for subscription, where customers bid for the features they want, at least two customers are required for features that seem very customer specific. Once customers have bid enough money the feature moves on to
project, and development starts – once its finished, they either give it to the customers who paid for it 3 to 6 months before anybody else gets it, thereby creating an incentive for customers to contribute to its funding. Or incorporate it into the Enterprise Edition of the product, thereby increasing the value of a subscription. Or donate it back to the open-source community, thereby getting help from the community for its downstream maintenance. In most cases, they do all of the above, in a staged manner, killing three birds with one stone

it’s a really great process and if I ever get a second chance within my company there are some ideas I would like to incorporate.

Finally Kathy provides an alternative approach to the process of defining a set of product features, that can be applied to all sorts of decision making needs where there are many options to choose from and perhaps refine. It’s a fairly long process, but essentially it has the following charachteristics:

The whole process is subject to a time contraint to explot constrain-fueled creativity
It involves getting teams to repeatedly pitch other peoples ideas, with the best options being selected. The clever part of this approach is that because the ideas being pitched are not yours it avoids attachment to your own idea
It leverages the wisdom of crowds (diversity-driven inspiration) by having a wide range of independent people involved in the selection process
It uses a lot of external inputs to spark inspiration, books magazines etc

I particularly like the idea of repeatedly pitching other peoples ideas and iteratively down selecting them until you get to the subset that you want to take forward. I think it could be creatively applied to be a much better approach than pitching up a management hierarchy.

The future of product management (1)

Steve Richards — Tue, 27 Mar 2007 00:18:00 +0000

This is part 1 – part 2 (to be published soon) looks at some recent articles I have seen that support this approach

In one of my day jobs I get involved with product management and I often find that bridging the gap between our limited investment budget and the poorly defined needs of our customers to be a real struggle, more specifically I find:

Customers are not able to clearly articulate their needs, and we don’t invest much in helping them do so
The metrics we collect from the services we currently deliver are not designed to give us insights into how that service needs to evolve
Customers are largely disconnected from the investment decisions that we make and so don’t feel that they are engaged in a partnership with us that is to the benefit of both parties (this is especially disturbing because we are engaged in multi-year contracts)
Neither our customers nor ourselves are well placed to plan for disruptive waves of change, so we both tend to wait until its too late. For us that means we fail to secure new markets and retain existing ones, for customers it means they miss out on opportunities to gain or at least maintain their competetive advantage

About a year ago I started to think about how we could improve the situation, and I came up with a new approach that would entail placing more control over our investment decisions into the hands of our existing customers, and internal company analysts responsible for spotting disruptions. In more detail I proposed the following:

Our customers are engaged in long term relationships with us, are motivated to help us and our fairy representative of the needs of future customers. This means we can largely trust their motivations
We can get a fairly robust short list of potential investment areas through our research into emerging trends and current service “issues”
If we converted our investment budget into virtual dollars we could give it to our potential virtual investors, these investors would be primarily customers, but also a small amout would be reserved for existing service delivery directors and our own researchers into disruptive opportunities
Potential investors would get a chance to review our short list of investment areas and suggest additions
We would present to customers our investment ideas in an event, in much the same way that companies seeking investment might pitch to VCs. During the event our potential investors would get the opportunity to grill us, suggest changes and discuss the options between themselves. Investors might need to sell their preferences to other investors in order to secure sufficient investment to make sure enough funds were secured to make their favourites happen
Once the new short list of ideas had been established a second round of funding would probably be required because some investments would not secure enough funding, in addition some customers might decide to invest their own real money to make sure some activities that were really important to them actually happened
Once all investments had been decided investors would often be strongly motivated to see them succeed and would hopfully offer to work with us in partnership
Customers would then track their invesments and be ready and waiting to “buy” the services once they were complete
We would continue to pole customers on their liklihood to buy so as to get reliable demand forecasts and to make sure the solutions were on track to meet their needs. In some cases we might need additonal investment funds as we moved through the development phases, these re-investments by our customers would keep us on track

Although initially we would probably allocate virtual investment money to customers based on the revenue we got from them a refinement to this scheme would be to reward customers in later years who invested in services that were most successful for us, making the scheme much more like a real investment market.

Unfortunately key stake holders in my company felt that this scheme was a bit too radical and I suspect that they were reluctant to give too much control over to customers.

The ideas for this approach were drawn from many sources, but briefly:

CFO magazine had a good article on the use of investment markets for improving decision making in business
The Wisdom of Crowds is a useful book that explains how a large group of independent peoples decisions can be aggregated to create decisions that are better than any individual specialist, if you like to listen to your research there is a good talk by the author available here and a great summary by Dave Pollard here
Tom Malone talks about the power of predictive markets here
Clay Christensen describes the concept of disruptive innovation here and here, that’s why in my approach I don’t allow existing customers to hold all of the investment but also reserve some for investment in continuous improvement and some for investment in disruptive alternatives
Dave Pollard provides a great summary of Christensens work on innovation here

Pulling a stagecoach with chickens

Steve Richards — Sat, 11 Nov 2006 03:58:31 +0000

I just read a great post that describes some of the challenges that face project managers. The basic premise is that it’s almost impossible to control a project because there are just too many people making too many decisions, but don’t give up hope the article provides a coping strategy.

The analogy used is trying to pull a stage coach with chickens – really great. Here’s an extract, but please read the whole thing!

The reason project managers can’t manage projects is because projects are unmanageable. The project manager’s responsibilities, as written, describe a fool’s mission. Provably unachievable.
The few who succeed resolve this eternal dilemma by more fully acknowledging it. They accept that, while their project is unmanageable, it might be capable of controlling itself. Not, however, by management command and pseudo control, but through conversation. I believe that most every project is capable of learning how to control itself, and that every element, every contributor, has something to provide to that conversation. Even, especially, the chickens.

The project managers who can’t create successful results don’t acknowledge that their projects are unmanageable. This acknowledgement could take them out of the driver’s seat and open the possibility for surprising, even delightful results. The alternative seems to be a stagecoach that eternally intends to, but rarely actually does, arrive on time, on budget, and on spec.

Real business applications of blogs

Steve Richards — Thu, 13 Jul 2006 02:10:00 +0000

Rod Boothby has an interesting article describing some the the real business applications of blogs. He chose managing projects in this example and I am a big supporter of this. I have spent a lot of time observing projects and programmes failing and think that blogs can play a really important role in fixing these broken programmes. I wrote about my ideas on how blogs would help a couple of years ago – so long ago that the term blog was hardly known. The essential insight is that project management is more about the people than it is about the process, and blogs are a great way to facilitate the necessary team dynamics and cross team dynamics that’s so essential to success.

Project management is all about the people

Steve Richards — Fri, 09 Jun 2006 00:29:00 +0000

I love the reforming project management blog, it has some great insights. As an architect/solution manager who has dabbled with project and programme management for 15 years I have found that all too often project managers get tricked into managing the project and not managing the people. A great example of this is a list of project management steps which lists 16 steps of essential project management. Hal then crisply points out in his comments:

It’s not a bad list. If you only followed Lee’s advice, then you would do ok with your projects. However…the author misses a central aspect of projects. Project participants are autonomous. They have the opportunity to say, “No,” even though they often go along saying, “Yes.” They also are likely to misunderstand what they are asked to do, just like you and I misunderstand what we are asked to do.

Projects require leader-managers who care for the project participants. The leader-manager sees that the participants are acting as a team — taking care of each other. Success depends on those relationships to avoid misunderstanding and to create a project setting where intervening in each others’ work is not seen as meddling.

I like to think of successful project management as all of the above, but also the management of the soft areas of team dynamics:

Co-development
Co-operation
Co-decision
Co-ordination
Commitment

Asking questions

Steve Richards — Sat, 08 Apr 2006 01:22:00 +0000

I have often noticed that the most impressive people I work with are the ones who ask the best questions, Hal has some hints on how to do this on Reforming Project Management. His key insight is to use the following two questions, in addition to the traditional who, what, where, when, why and how:

Here are two more revealing questions.

Why do you say that?
What possibilities are opened (or closed) for me (us)?

The first question is an invitation for the speaker to say more about his/her statements/opinions. The answer to the question reveals how the person sees the world. The question is encouragement for the speaker to continue speaking.

He also adds some useful advise though, because great questions can be pretty scary!

Be careful…adopt a stance of curiosity when asking the question. Otherwise, the speaker may interpret your questioning as an inquisition.

In my experience I found the – What possibilities are opened (or closed) for me (us)? – question to be very clever, one of my customers once asked me to answer it for the fixed price project we were delivering too them, by making a great answer to the question mandatory they essentially forced me to go beyond full disclosure, requiring me to get the whole team to think of every pro and con that we could, and discuss and debate it with them, it was a great tool to bring customer and supplier closer together.

Mind Mapping Projects

Steve Richards — Wed, 22 Feb 2006 18:10:00 +0000

I thought I would share another of the ways that I use mind mapping, to create a project plan. Mind Manager (my tool of choice) really lends itself to this because you can export a map to a Microsoft Project and synchronise changes. Although I don’t use the sync feature that much I find it far better for creating projects than Microsoft Project for the following reasons:

Mind maps encourage you to think about the structure or shape of the project, it really is trivially easy to visualise even very complex projects and to merge and re-structure them as your understanding evolves
If you are brainstorming a project, its MUCH easier for other team members to keep track of what you are doing in Mind Manager than it is in Project
Mind maps use screen area much more effectively that one dimensional outlines so you get to see at least twice as much content, without suffering from information overload
Its easier to jump around the mind map for example to show the whole map and then tunnel into an area of interest, and to resize the map so it fills the screen
You can add icons, images etc, that provide visual queues to help you relate to the content, and you can add icons to represent additional dimensions to your map, for example priority, or to flag problem areas
Its much easier to add rich text and link documents to your map, without adding clutter.

In summary as an Architect/Solution manager I tend to use mind maps to define the content and structure of a project, once that’s been brain stormed and reviewed, we export the map to Microsoft Project, add dependencies and resource types and then hand ownership over to the Project Manager who adds resources, milestones and administrative tasks.

Productive Friction and Innovation

Steve Richards — Thu, 28 Jul 2005 16:31:19 +0000

In some recent discussions I have been introduced to the concept of “productive friction”, which is an effect that’s created when team members with a diverse background get together. It happens for example when people from different cultures or academic disciplines or companies work together to solve a problem and it increases the level of innovation. John Hagel describes it in his book The Only Sustainable Edge and in his Article in the Harvard Business Review.

This recent article in Newsweek describes the effect, and gives some practical and simple advice on how to take advantage of it in your projects:

What they found was that the most successful teams did two things right. First, they attracted a mixture of experienced people and those who were newcomers to whichever field they were in. That’s not surprising–the need for fresh blood has long been recognized as an important ingredient in success. The second criterion, though, was far less obvious. What successful teams had in common was at least a few experienced members who had never collaborated with each other. “People have a tendency to want to work with their friends–people they’ve worked with before,” says Luis Amaral, a physicist at Northwestern and a coauthor. “That’s exactly the wrong thing to do.”

Blogs and social networking tools help people establish the essential connections between experienced people with different perspectives, and this is one of the main reasons why I keep a public blog, and long for an internal blog, or an alternative mechanism:

The study also suggests a role for technology in bringing seasoned people together. Tacit Knowledge Systems, a start-up in Palo Alto, California, is marketing a computer system that links people with similar professional interests. The system monitors e-mail in a corporation or other large organization and keeps tabs on what employees are interested in. If a worker is looking for somebody to collaborate with, he or she can query the system to find somebody appropriate. Tacit is developing a new version that actively forges connections by prompting employees when it finds people who, on the basis of shared interests, might make a good team. Finding a way to maximize creative potential is one of the most pressing problems in corporations. Knowing what makes one team more creative than another is an important first step.

If you want to find out more, but don’t have the time or the money to follow the links above, I recommend you download and listen to these two interviews from IT conversations.

In this IT Conversation Dr. Moira Gunn speaks with John Hagel, who with co-author John Seely Brown, has written “The Only Sustainable Edge,” a new perspective for business.

In this IT Conversation, John explains why he considers web services to be a “deceptively disruptive technology” and why he’s an advocate for web-services strategies that focus on the edge of the enterprise rather than lower-return internal integration projects. “Companies are losing opportunities by not thinking systematically about the technology,” he says.

Simple model of personality type in business

Steve Richards — Thu, 28 Jul 2005 04:20:00 +0000

Andre has this simple and easy to interpret model for classifying people in business:

Builders – At the front of every train you typically have the entrepreneur. Entrepreneurs are all about ‘what could be’. They envision the world the way they want to create it and then set out to make that vision a reality. Entrepreneurs are typically described as both visionary or charismatic.
Executers – In the middle car you have those that were born to execute. Executers might not brainstorm your next innovation, but once an idea is hatched, they can execute the heck out of it.
Protectors – At the back of the train you have the protector. Neither innovation nor execution mean anything to a protector, who is motivated only to protect and guard what’s already been won in terms of assets. Protectors are better at saying “no” than anything else, for fear that any movement might somehow diminish or dwindle what’s been harvested by those before them.

It’s a lot easier to interpret than many models I have seem.

This looks like a book I should read

Steve Richards — Mon, 18 Jul 2005 00:04:00 +0000

Although I am more of a solution manager than a project manager I have managed 30 odd projects in my time and a fair few programmes. I have gradually developed a dislike for formal methodologies and templates because of their tendency to prevent the team from thinking. That said I think there are some key management skills that every project team needs, but I have rarely seen described very well. This book looks like it is my sort of style, it in my Amazon favourites in case anyone wants to buy it for me.

Shipping Software

Steve Richards — Fri, 01 Jul 2005 17:16:00 +0000

This is a great interview with Tim Marsland who is a distinguished engineer and CTO for the Operating Platforms Organization in Sun Microsystems. In the interview he talks about the approaches Sun takes to the process of test, integration, compatibility and shipping Solaris. It gives some great insights. I particularly liked these sections.

First they use daily builds and eating your own dogfood (but don’t use that term) , I really like the daily build concept as I have described in previous posts:

We also use the previous night’s build to build today’s system, and every two weeks we put the latest build on the shared file- and mail-server for a large proportion of the operating system development group. We deliberately hold our own feet to the fire. Developers quickly got used to running their stuff on their own desktops and their build machines before integration.

Next a section to use when your manager asks you “why do we need to install the beta”

A few months later, we came up with another interesting idea: the Platinum Beta program. This is an idea where we say that we think our beta software is good enough for the beta tester—not just to kick the tires, but to put it into a production setting. This seems a gigantic risk for a customer to take; the way we made that possible is by giving the customer the support of a development engineer 24/7. Customers in the program get an engineer’s pager number and can call any time and rapidly get workarounds and fixes for their problems. The great thing is that there are customers who are keen on working with us that way because they value the relationship highly and welcome the ability to interact with the engineering group at that level.

This section is great, it talks about the fact that “testing” in a controlled environment never finds all of the issues, and it also demonstrates the value of making the development team use their own software or the system they are designing to support themselves. In Sun’s terms the development team become a sort of internal Platinum Beta programme. I particularly like to make sure that the project and programme managers use the systems they are managing the development of.

When customers do that, they find a completely different set of problems than we do. Obviously, one of the things we’re concerned about is that all of our internal alpha usage is about the things that we do. If you ask “normal” beta customers to test things, very few of them deliberately put it into a place where they’re relying on it, and once they find their first bug, they often give up. The people who are in the platinum program are willing to press on and discover more, particularly if we can fix their problems quickly. The program isn’t very large, but those customers do a production deployment and the engineering team learns an enormous amount from the experience.

Of course when you do lots of real use testing with dedicated users who will help you track down the bugs quality goes way up, a great advantage that the Open Source development community have when developing tools that they actually use.

Once we started down that path, we realized that we were producing “beta releases” that were of equivalent quality to other companies’ production software. We didn’t arrive at that opinion by ourselves. Our customers told us that.

I also like the idea of incremental delivery, very similar to the daily build concept of incremental development build delivery. Both have the advantage that a large system evolves in small increments that work before the next increment is added. At any point in the process you can stop and what you have works, or very nearly with just the last few small changes needing to be debugged. If you take the big band approach you end up with hundreds of components that nearly work all having to come together at the same time and be made to work, MUCH MUCH more difficult.

That was the genesis of Solaris Express, which is the near-continuous delivery of new stuff. We argued that if we’re using the software internally as part of our production environment, then why not allow our customers who are interested in getting new technology to have access to that software, too.

Good insights into corporate blogging

Steve Richards — Wed, 29 Jun 2005 17:27:00 +0000

Dave Pollard has a good introduction to corporate blogging, here. Dave’s work is consistency good and he also tends to get great comments which complement the posts.

Information Overload – and burn out

Steve Richards — Mon, 02 May 2005 19:42:22 +0000

Eric, builds nicely on my last post on “Information Overload” and provides some nice links. I particularly resonated with the idea of “shutting down” in the face of overload (burn out):

Have you ever found yourself emotionally shutting down in the face of a daunting project list and an overflowing e-mail in-box? I have. The Air Force calls this Task Saturation and it can manifest itself in many ways. Some people hyper-focus on their email and new-mail alerts to the point where nothing gets done.

David and I made posts on Saturday and Sunday about the UK researcher who found that email distractions can cause a drop in IQ.

Fellow productivity blogger, Bert, from Open Loops, posted an excellent comment about how the military helps its pilots extract themselves from overwhelm before they have to extract themselves from their wreckage:

This has certainly happened to me a few times when I have been on major programmes and just unable to get my mind around what to do next. In these circumstances I tend to take the following steps:

Write everything down on a piece of paper, I often never look at this list again
Take afternoons off for a few days, often going for a walk or the cinema, anything to take my conscious mind off the lists.
After a few days I find I know what to do again, often what I do is completely re-plan the programme.
The rest period is key for two reasons, it lets me distill out exactly what’s wrong with things as they were when I hit the overload brick wall and it prepares me for a weeks work re-planning

It’s worth pointing out that I am not a programme planner, however when things get into the state that I hit information overload, its almost always the case that the programme is out of control, and no planner is ever going to get it back in control from this point, so I pull my architecture team together and we help the planners to sort things out. Amazingly I have found several times that the planners never realised anything was wrong until the architects said STOP!

For more posts that comment on programme management, checkout this list.

The need for a balanced management team instead of Super Men

Steve Richards — Tue, 21 Dec 2004 00:27:00 +0000

This is the second in a series of articles that look at It Infrastructure Programme Management from an Architects perspective.

I often see programmes fall into the trap of over reliance on certain individuals. Unfortunately the more effective and useful a person is the more that person seems to be branded “Super Man” and burdened with commitments that make it ever more difficult for them to do the things they were valued for in the first place.

When I started thinking about this short article I had in mind a few examples:

The Programme Director who takes on too much Programme Management because the customer and account teams except him to have programme management detail at his fnger-tips. Solved by a combination of excellent management information, setting expectations and not being afaid to re-inforce those expectations. Fall into the programme management trap and you won’t be there for the team when they need you, won’t have time to manage the key relationships and won’t be able to see the wood for the trees, the classic “programme is red – suprise!”.

The Chief Architect who forgets that his job is to preserve the conceptual integrity of the solution and to nurture its evolution through logical and physical development stages. Solved by having a very good definition of the concept initially, making sure that the architecture leads responsible for the logical solution definition have a clear understanding of the whole concept and making sure that as the solution definition progresses it is regularly cross checked against the conceptual definition and either the concept changed or the logical/physical definition bought back on track.

However there’s more to this team idea than that. First we need to make sure that the programme has a team structure that allows all views to be well represented, ideally I like a model that does not create conflicts of interest, and provides people with sufficient time to support their teams. There are some of the key roles I like to see.

A Programme Director – note the emphasis in this role on directing. I never like it when I have a programme director who is too BUSY, ideally they get home by 6:00PM. They need to be their for their team, and to manage key relationships and to see the big picture and resolve the big issues. A programme director who is working more than 48 hours is managing, not directing. Personality wise they need to be very approachable, not afraid of bad news and always happy to talk, at the same time they need to give key stakeholders confidence that they have a good team and good processes and that these are well executed.

A Chief Architect – resonsible for ensuring the the solution that is delivered meets the objectives that it is designed to meet. He achieves this by ensuring that the solution has conceptual integrity, and achieves this by designing the way the solution will be described and verified. Most of the points made about the Programme Director apply to the Chief Architect as well. Its also worth remembering that on many infrastructure programmes, users don’t know what they want!

A Programme Office Manager – primarily responsible for ensuring that the programme management team receive the information they need to direct and manage the execution of the programme. This primary role is one of supplier to the programme management team. If this information provision role fails, the programme usually fails. The secondary role of the programme office is to ensure that the programme level processes, (those followed by every project), are executed correctly, (evidence of this should be part of the management information). In my view the Programme Office manager’s role in the Programme Team is not as a contributer to the management of the programme, but as a supplier of information, so he needs to be in the meetings, so he knows what information is needed first hand.

Development Manager – responsible for executing the projects that develop the solution. The emphasis is on execution, not definition. The project content should have been defined conceptually at the programme level, it is refined by the projects as the logical and physical level definiton is created. Individual projects should not be allowed to change their scope, project scope is owned at programme level. What do I mean by scope:

The conceptual architecture, the functional service definition, key volumetrics, budget, major milestones and dependancies, principles, assumptions, issues and risks.

Customer Experience Manager – there are two issues that generally fail to to be managed well on large programmes. The first is the user community is rarely well prepared for the change that is about to hit them, and certainly ill prepared to exploit it once it has arrived. The second is that the disparate deliverables from the programme do often not integrate very well from the perspective of the end user. This role is designed to solve this problem through ownership of a variety of elements, including, end-user communication, end-user organisation and roles, solution integration testing, dog-food testing and piloting, user acceptance testing, end-user training and documentation, the end users deployment experience, the end-users post deployment experience, customer surveys and other end-user focussed programme success metrics, exploitation. Ultimately this person is the users advocate, an interesting video that illustrates some of these points is available here.

Service Transition Manager – Each project that is delivering services that need to be operated and managed needs to take ownership of ensuring that these service elements integrate into the management infrastructure and have processes that have been developed, accepted and implemented by the lines of service responsible. The role of the Service Transition Manager is to ensure that the lines of service are ready to accept the services and processes that have been developed. This means ensuring that they have the right level of resources, budgets, trained/skilled staff, that they understand the processes have metrics in place and management processes in place etc. In many ways this person acts as the Programmes agent within the operational organisation working to ensure that the delivered services are success.

Deployment Manager – responsible for execting the deployment activities on the programme. It depends on the programme the degree to which deployment processes/tools are developed by deployment/development and its largely an issue of skills, for complex deployment activities that are executed a small number of times, my preference is for the development team to do the development of the deployment process/tools, (and sometimes even do the deployment). For processes with less technical complexity it’s often better to develop them within the deployment programme to increase ownership.

The programme management team should not be afraid to create additional programme level roles, to reduce the burden on them, for example roles focussed on communcating with business stakeholders. However these should report to one of the team identified above. This group should be selected to work as a team, and motivated to do so. Ideally they should be colocated and should be encouraged to meet ad-hoc and not just at formal risk/issue/change/status meetings.