Adventures in home working

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.

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.

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.

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.

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.

This is the first in a series of articles about Programme Management.  Many of the things I am going to say apply to project management and to management in general but Programme Management is my focus.  I need to start by setting the scene. 

My experience is enterprise IT infrastructure programmes, so that’s what I will be talking about.  By Programme I mean a collection of projects with many dependencies between them.  By IT Infrastructure I mean all the common IT services that a business needs, desktops, portables, file, print, directory services, communication, collaboration and coordination services, systems management etc, you get the idea.  On my biggest programme, we had approaching 90 different server types so I won’t list them all.

Anyway onto the first topic:

“What does he do? The importance of top down Journal keeping to programme communication, coordination and team spirit”.  

Why you may ask did I pick this topic first?

·        because almost no one does it

·        because it can make a huge difference for very little cost

·        because communication and collaboration and coordination are key to any programme and journals help with all three

·        because I happen to like blogs and think they make a great tool for journal keeping

Lets look at a some of the characteristics of programmes and leadership and how journals help:

• Programmes have lots of people on them, and many more people who will be impacted by the programme.  It’s difficult to know who to communicate to and what to communicate and when, to keep everyone happy.  Blog like journals are great for this.  The more senior the person the more important so as a minimum I recommend journals for Programme Managers and Solution Architects as these are the team members responsible for stitching the whole programme together.  However, the idea cascades down the hierarchy very well.  In my model I recommend that the doer’s blog what they are doing and link to the background material that has influenced what they do, and any decisions they have taken or are trying to take.  Project managers blog the changes, status and deliverables of the project as they are produced, architects blog like a doer, but also blog change and technical debates that the rest of the team contribute to.  They link to key issues that doer’s blog about, that may affect other people in other hierarchies.
• Programmes are constantly changing, and it’s difficult to keep track of the changes, the rationale behind them and the impact of them.  Formal change logs solve these problems in a dry way but they rarely capture the background and impact in the same way as a journal does.  For example they don’t talk about the impact on morale, resources and cascade changes – especially those that come to light after a change has been approved.
• Team members rarely understand what their leaders and peers are up to, the higher up you go in the hierarchy the more confusing it is for the people below.  Too often if you ask an engineer what’s drawing on his programme managers time the answer will be “lots of meetings”.  How would the answer change if the team read the programme managers blog: “he is focussing on locking down the release schedule with the customer and reviewing the overspend on project X, and preparing for the programme review next week.  It’s been a tough week because he has to do a Customer Care course for two days and his wife is ill so he had to get home by 5:00 to look after the kids this week.  The customer is however unhappy because the they want 2 releases rather than 3, but our current position is that this is too risky and he want’s input from the team on whether we could mitigate that risk in any other way”

So you get the idea, lets be more specific about the benefits of a journal, delivered as a blog:

• Writing helps you get your thoughts straight
• You control the message, this can be very important at all levels in the hierarchy.  Often guys at the bottom rarely get to communicate with guys at the top except in 20 minute “team meetings” which are often conference calls and very much one way channels for 5 minute sanitised summaries
• You can get feedback directly and interactively
• Your audience decides how much information they want, depending on which categories they subscribe to
• The team start to pull together because when implemented top down, everyone’s understanding of each others problems and successes, constraints, frustrations etc is greatly improved
• It provides a mechanism for everyone to demonstrate their contribution/value to the programme
• It helps with the management of and identification of dependencies and change
• It’s less likely that myths – my projects “green” – will propagate up to the top without someone questioning it
• It makes it much easier to add resources to the team, or replace existing resources – they just need to read the blogs for a day to get up to speed
• You can add system generated blogs for example document check-ins. changes log updates, risk log updates.

I have managed a lot of IT Infrastructure projects in my time, and a couple of smaller programmes.  I have also keenly observed the management of several large programmes as a Chief Architect.  This article is written from this perspective.

Some initial observations:

1. IT Infrastructure Projects generally fail from at least one perspective and often more
2. IT Infrastructure projects look superficially simple
3. The programmes have been overly influenced by the personality and skills of the Programme Director

The following are a set of Article Titles that I intend to write over the next year or so; they give you a good idea of the issues I think are important:

1. What does he do? The importance of top down Journal keeping to programme communication, coordination and team spirit
2. The need for a balanced management team instead of Super Men
3. Management information is a team resource
4. The customer is not the same as the client
5. Objectives and Requirements, why they are different and both important
6. The importance of programme maturity reviews
7. Conceptual integrity and how easy it is to loose it
8. The lost art of estimating – take different perspectives
9. How to plan a programme, top down meets bottom up and debates
10. Why has my green programme suddenly gone red, (see next topic)
11. How to milestone a programme
12. Avoiding death by meetings
13. The importance of “assumed responsibility” to successful scope management
14. The importance of “eating your own dog food” and “daily builds”
15. Achieving autonomous – coordinated – motivated teams
16. Making the most of a co-located team
17. Mitigating the risks of a virtual team
18. Risks, Issues and Change a collective responsibility
19. Key programme documents and processes
20. Dangerous metrics and incentives
21. Understanding the relationship between DCO,TCO and TVO
22. The “red team”, or what to do when it all goes wrong