Project Management

I project managed production and upgrading of outdoor displays and builds for a number of contracts using the job kits system I developed which broke the work down into simple jobs that could be done reliably with casual labour and also made stock control very easy. In addition I managed the R&D software development for the Tyrell1, Tyrell2 and Tyrell3 products described under Software.

Managed production of IDU (TV style outdoor display)s and LCD1 (flat screen outdoor display) all ran to time. The Tyrell software development projects lead to a core product for the business though Tyrell3.

All production of hardware I managed ran to time. This was due to the use of general labour and the job kits system I developed which also made stock control very easy. I allocated and applied basic principles as regards time to change a tool versus time to change a job when producing many items of the same type.

I managed three major software development projects one of which is now one of NAL's key products in the rail control rooms and the third of which is intended to replace the first with an integrated transport information system, providing live information to both staff and public as well as planning and incident handling facilities based on an innovative database design.

All of these research and development projects overran their expected completion dates despite careful planning using traditional methods.

Although the nature of R&D is that it is covering uncharted waters and so does have an unpredictable side to it, I think that this is an easy excuse with which to hide poor performance. The Tyrell software projects exceeded expected delivery dates for four main reasons; programmers were seconded for other work at short notice, requirements changed as we found better approaches, we did not foresee the complexity of the task, and I was not always able to accurately asses programmers performance.

Programmer Secondment - Most secondments were because product deliveries took priority over R&D which makes sense.
Requirements Change - In R&D the solution isn't always clear before the project starts. One can stick rigidly to a plan or gain advantage through revising the plan.
Unforeseen Complexity - R&D is not travelling a well known road and so not all obstacles can be foreseen. The question though is which obstacles should or could not have been foreseen. This is a question of the performance of the individuals concerned.
Performance Assessment - Effective performance assessment is vital for any manager. Performance assessment is not something that can be done by simply looking at the figures. Good performance is something that can only be done through knowing the job being assessed inside out so as to know what is or what is not a legitimate reason for a deviation in performance.

I had good 'C' programming experience but the Tyrell projects used 'C++' and 'Java' so I could not accurately asses performance and had to rely on programmers views of their own capability. Some programmers were not capable of the work asked of them but did not know it, some were not capable of assessing their own time for a tasks and some did not implement the simplest solutions to meet the requirements. (Notably we also had compiler problems when the code reached a certain size, thanks Borland.) Since my time was split between many activities, gaining experience programming in 'C++' and 'Java' was never quite high enough a priority. This was a mistake if I was to manage rather than just direct the Tyrell projects.

An alternative solution was to appoint a manager. Initially we chose one of the team members by consensus, but he would not discuss any failings of his team. Second we brought in an outsider who would discuss the failings of his people but proved incapable of discussing his own. The third appointed September 2003 proved to be the kind of manager required. As a result two programmers were removed from the team, oddly enough both had computer science degrees, and I was left directing and mentoring on user interface and database design matters. This worked.

In April 2004 we started using in house software tool, developed to my specification, to aid task management which gave us an effective day to day time logging and planning tool.

There is no doubt that there are special problems linked to innovative projects and especially software projects as Juran's Quality Handbook testifies.

Some suggest that there isn't a project methodology suited to innovation but this I think is simply an excuse for bad management. However there is no doubt in my mind that the critical factors in R&D project management are not well publicised.

Oddly enough some of the more useful project management texts I found were for building construction projects, not software projects! I guess this reflects the relative age of the two industries.

Reading;

"The Interactive Project Workout" by Robert Buttrick published by Prentice Hall.
"Project Management in Construction" by Anthony Walker published by Blackwell Publishing.

Task Management

The task management system software I designed at NAL was implemented as a minimal and incomplete software tool sufficiently to allow us to dynamically review and reallocate time spent on tasks in the manner we wished. Before developing this we used Microsoft Project, Prima Vira and many other tools but none seemed to offer the simplicity combined with the structure we needed.

When an organisation performs a task, such as the development of a new and innovative product, it is almost certain that the path to completing the task is unknown and will only become clear as the task progresses.

Even if the path appears mapped out at the start, in truth this plan is simply a plausible path based on a large numbers of unknowns. There can be no neat Gantt chart to discovery.

However this in no way means that innovation should be entirely freed of constraints or the need to look back and ask whether the best path was taken.

There is a difference between additional work that is the result of poor performance and additional work that is the result of what could not be foreseen. Identifying the difference and acting on it is vital to the effective management of an innovative team.