Adventures in home working

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

1. On a large activity conceptual integrity is really difficult to achieve and maintain
2. 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.

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:

1. identification, where an initial list of options is proposed, added to, discussed and rated, then they moves on to
2. estimating, where a specification is drafted, effort estimated and a rough cost is developed, then they moves on to
3. 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
4. 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:

1. The whole process is subject to a time contraint to explot constrain-fueled creativity
2. 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
3. It leverages the wisdom of crowds (diversity-driven inspiration) by having a wide range of independent people involved in the selection process
4. 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.

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:

1. Customers are not able to clearly articulate their needs, and we don’t invest much in helping them do so
2. The metrics we collect from the services we currently deliver are not designed to give us insights into how that service needs to evolve
3. 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)
4. 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:

1. 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
2. We can get a fairly robust short list of potential investment areas through our research into emerging trends and current service “issues”
3. 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
4. Potential investors would get a chance to review our short list of investment areas and suggest additions
5. 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
6. 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
7. 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
8. Customers would then track their invesments and be ready and waiting to “buy” the services once they were complete
9. 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:

1. CFO magazine had a good article on the use of investment markets for improving decision making in business
2. 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
3. Tom Malone talks about the power of predictive markets here
4. 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
5. Dave Pollard provides a great summary of Christensens work on innovation here

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.

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.

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

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.

1. Why do you say that?
2. 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.

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.

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.

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

1. 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.
2. 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.
3. 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.