Monday, August 24, 2009

Herding cats

Just before I left Perth, Martin advertised for a Project Manager for Moodle HQ. I think this is probably a good thing, if a good person applies and is appointed. However, I also think it will be a very difficult job to do.

Martin always has too much to do, and any time he can identify some tasks that can be delegated, it is a good thing. Early in the history of Moodle HQ he found Mike and Darlene who run a lot of the commercial side of the Partners network. More recently he appointed Helen to act as community co-ordinator, and Jordan as system admin. All those were successful appointments, and having watched form the sidelines I have seen that Martin will not recruit someone unless he is sure they are right for the job (important when you are running a small business) and Martin is a good judge of people.

The other reason a project manager would be a good idea is clear to anyone who had been following the Moodle 2.0 development, which still has a long way to go until it is finished. Someone with more time than Martin has to ride herd on the process can only help us get 2.0 out of the door.

However, it is not quite that simple. On the one hand, I have studied the Open University Project Management course from their Postgraduate Computing program. That is an excellent course, and as a result I know a bit about and am interested in what project managers do. On the other hand, I also know the fairly independent way that I and other core developers like to work. That is why I chose the title of this blog post. (Not because of some people's user profile pictures!)

To start with, the Moodle project is not even a project in the sense that Project Managers use the word. A typical definition is "A project is a temporary endeavor, having a defined beginning and end," but Moodle itself will not end (we hope). Still, some of the things we do, for example, the Moodle 2.0 release, are projects in this sense. However, we know there will also be another project called the Moodle 2.1 release later. Therefore, if we contemplate a short-cut that would let us release Moodle 2.0 sooner, we have to balance the short-term benefits with the long-term costs of cleaning things up in a later release. Classic project management tends to think about one project at a time.

That ties in with Moodle's choice of feature-driven, not date-driven releases. We will pick a set of features to be included in a release, and we will release when they are done, tested and bug-fixed, however long that takes. Well that is the general policy, but a certain amount of pragmatism is applied when interpreting it. This is a fairly unusual way to run a project. For example, with the Open University's Moodle-based VLE we operate the other way. We have date-based releases, with the dates announced a long way in advance, but we do not guarantee what features will be an any given release very far in advance.

Then there is the the nature of the work. One area where project management is generally successful is in construction projects. The cliché old maths problem "If it takes 2 men 7 hours to dig a trench 6 metres long ..." has at least some relevance to reality there. There is even the Bluebook cost guide that has established estimates for certain types of construction work.

In contrast, as that classic of software project management "The Mythical Man Month" says, "adding manpower to a late software project makes it later." What software developers do is much closer to an architect drawing the plans than to a builder laying bricks. The compiler (or PHP interpreter) is the builder. This is hardly new, and is why agile software-development methodologies were invented. If Moodle's new project manager is going to adopt a Methodology, I hope the choose an agile one.

Another difficulty is that software developers are not fungible. If there is some tricky job involving security you probably want Petr to do it. If it is to do with the quiz, it would be best if I did it. If it is related to backup and restore, no one wants to do it, and so it ends up with Eloy ;-). If those people do the job, it will be quicker. On the other hand, sometimes you want to give the job to someone else, to increase the bus number of the project. While this sort of think makes the project harder to manage, it is the sort of thing that a good project manager knows how to deal with - once they get to know the people involved.

Another consideration is that developers are highly distractible. That is, while they are working on one thing, they may suddenly notice that something is a bit messy, and decide to rewrite it or refactor it, even if that was not part of the original plan. When considering the long-term health of the moodle, that might be the right thing to do, even if, in the short term it delays the next release. At other times, it might just be self-indulgance and cause bugs. Would a project manager be able to tell the difference? Anyway, as some-time tiddlywinks world champion Andy Purvis once told my, after thrashing me soundly, "Strategy should be a mixture of planning and opportunism."

A final potential problem is that the Moodle core developers are a highly motivated group of people. We care a lot about Moodle, and have demonstrated that over the years. We don't need to be told what to do, and a project manager who tried could piss a lot of people off very rapidly and do a lot of harm to the project. Fortunately, I think the chance of Martin appointing someone like that is tiny. However, I think is an important point to make, that the Moodle Project Manager should be a colleague and peer of the developers (with a particular set of skills). That is, they should manage the project, not the developers.

So, I have said that I think a Moodle Project Manager is a good idea, but I have also said why I think it would be a very difficult job to do. So what do I think the Moodle Project Manager can usefully contribute (that I, as a developer, would not object to ;-)).

A good project manager is always a good communicator, and in multiple directions. The Moodle Project Manager will need to communicate with the developers to track as clearly as possible what development is going on, and what still needs to be completed before the next release. They then need to communicate that picture of where we are to all the Moodle administrators waiting for the next release, including the Moodle Parters. They also need to communicate it back to the developers to help them see what progress is being made and what the priorities. Naturally they will be working closely with Martin. They also need to communicate progress to Translators and third-party plugin authors, to help translators have their translations ready as soon to the main release as possible.

A project manager is also good at extracting clarity from a confusing situation, which is really another part of what I just wrote. They can take reports from a lot of people, and a more-or-less vague list of outstanding tasks, and combine that into a picture of where we are now, and where we are going that other people can understand.

Once you can communicate well, and as a result derive a clear picture of where we are and where we are going, then the actually project planning - getting the right people to work on the right tasks next - is relatively easy, but still requires some knowledge of the people and the tasks. Then there are the people skills to help keep people motivated and focussed on the next release without trying to over-manage them.

Finally, and particular around the release time, a project manager can improve the processes. For example, does Moodle need string and user-interface freezes in the run up to the release, to help translators and theme designers? (The answer needs to be a consensus of all involved, so more communication.)

The project manager will also be one of the people in a position to hear what new features people are most desperate to have next, and so will be able to contribute to planning the scope of future releases.

So, it is a challenging job, but I think someone is needed to do it.

5 comments:

  1. I really enjoyed your post Tim, it brings me back to when I worked as a software developer. The PM you describe will need a unique skillset, in particular the ability to ensure the focus of developers whilst also encouraging them down the important tangents I thought was nice.

    I have a question? Why does OU Moodle have date-based releases? Is this to tie in with the acamedic year or a University Strategy or something? In fact now that I think about this it makes a lot of sense. It is really a release strategy focused on users and not developers. An interesting model that maybe more software projects should try (particulary ones aimed at education which can only be planned according to academic calendars).

    - Eamon
    eamon dot costello at dcu dot ie

    ReplyDelete
  2. That is a good question. The OU does not really follow an academic year - different courses start at different times of year (primarily February, May and October/November), and then the presentations overlap, so there is no time when our VLE is not being used. However, there are peak times of new course starts and exams that it is worth trying to avoid.

    However, the real reason for date-based releases is coordination with all the other people within the OU who need to be involved with the release. The testing team who need to test each release between the 'code freeze' date and the release date; the service team who are involved in rolling out any new functionality; and so on. They need to be able to plan their workload in advance.

    So that is why release dates need to be announced well in advance. That does not say why every three months. Well, the balance is between being responsive enough to people's needs, while leaving enough time to actually get things done between releases. During the initial stages of the project, it was closer to 6 months between releases, which worked well when there were large chunks of integration work to be done. However, at times there was pressure to roll out new stuff between real releases. That was a mess. The three months we use now seems to be about right for where we are now.

    Then there is the question of which months to use for the every-three-months pattern. The consideration there revolves around Christmas (late December when almost everyone is away for about two weeks) and the summer holidays (late July and August significantly reduced staff for several weeks). Also, the common course start and end times.

    So yes, you can view this as a user-centred approach. However, for developers it is perfectly workable. You develop new functionality on a development branch, and only merge it into the main CVS repository/branch when it is finished and working. Git would support that workflow even better, and one day we will probably switch from CVS.

    ReplyDelete
  3. Very interesting Tim. I had forgoteen the OU has rolling enrollments. From the perspective of a small Irish University doing a minor Moodle version upgrade once a year, with only the default core Moodle plugins involved, is a big deal so its fascinating to think about the scale of the logistical operation that OU Moodle must be. Particulary as I am guessing you have some kind of fork of Moodle?

    Interesting that cycles are shorter now than during intial development. Stability becomes increasingly important over time I guess in a production system.

    Thanks again for the insights into OU Moodle.

    (I have not used GIT before but am planning to some research on Moodle code soon and may use it.)

    - Eamon

    ReplyDelete
  4. We try very hard to ensure that it is not a fork, and we do upgrade to the latest stable version each quarter.

    The single most important rule is to use the recognised plugin points (modules, blocks, themes, reports, ...) wherever possible.

    For places where changing core code is the only way to get what we want, we mark the changes clearly, and try to get our changes contributed back to the community.

    Still, the area between customisations and a fork is a grey one, and it is a constant struggle to keep on the right side of it.

    ReplyDelete
  5. Excellent post. You have thoroughly explained what a project manager really does. This post makes me really gives a lot of information about project management and Moodle 2.0 too!

    I really have fun reading your post. Thanks a lot!

    ReplyDelete