The System is the Project.

and the Project is the System.

Two of my (sucessful) Systems Engineering MSc students had this to say about system development projects, from different angles:

The architecture of a system and the organisation of that work are fundamentally interdependant.

Well, duur. Aside from the obvious, we spoke at length about the two sub-systems: the product side and the project side. Like all systems, you don't want to optimise any one part, but the whole.

Here's another case: software (specfically, database) development at Flickr (a burgeoning product, with a comparatively tiny dev-team). Sometimes the usual quality criteria on the product side may be better compromised if you want to achieve desirable behaviours on the project side. Ergo, by way of interconnected, don't bother normalising your data tables like you were told in college.

Starting research

Setting out a research agenda is hard. I should know. It's possible (probable) that if there's the freedom to spend time doing any research at all -- if the effort it's not results-driven -- then the initial directions are hard to define. That can lead to difficulties in making the final stages of the work yield value for the numerous stakeholders. These difficulties are endemic to Masters and Doctoral theses but are common in "higher", team-oriented, research efforts too.

Some work and proposals flowing near me have crystallised some views and criteria, all of them pretty obvious and well-known:

• In the beginning, seek to define the terminology and knowledge landscape under study. This establishes a beginning place.
• Have a working hypothesis (Proposition A), and work for or against it (transforming it into Truth A). This is an initial direction. Even though it may be a stalking-horse, it should be conceivable that demonstrating the hypothesis could be a goal of the research.
• Tools (e.g. Tool A) you acquire to deal with knowledge and statements shouldn't be an end in themselves.
  
• Be prepared to abandon the hypothesis if it looks inappropriate to what can be found. Don't proceed without forming a new one (Proposition/Truth B).
  
• At a later stage, you might be fed up with hypotheses (too many of them, self-evident by now, etc) and may wish to progress towards demonstrating a usable product (Tool B). That's fine, but again, don't abandon the hypothesis/es until you can define B's characteristics.
• Keep defining the targets of the proofs and products in terms that the audience of the research will value (this does not necessarily mean that ready Applications are always required).

What's most important? If you come away with a Tool B, then that's something in itself. Then, less vitally, Truth B, then Truth A. Tool-A's are incidental (but creditworthy). The whole thing is creditworthy if the above paradigm is followed adeptly.

This article has turned into Marking Research, which is as it should be, since Specification must always have its own Evaluation in mind.

Small tools

I was having a discussion about how PM syllabi are becoming full of trophy topics, straining new entrants to the field with a weight of learning objectives. A sign of maturity? Not necessarily. Mature thinking might be about letting go of childish ideas, keeping what you really need. Hence: let go of monetary flow control routines; grasp the idea of measured work value.

A bunch of stuff I've come across recently seems to be about light toolsets. Some of this from Innovation Weblog.

Mayomi is a web application for mind maps. Not very rich yet, and certainly not dynamic. When I pick up a tool I expect to be able to mess around with scenarios, rather than document perfected thoughts (the essential fact that makes thinking with Excel different from declaring with Word). One to watch. The developer makes the most of post-HTML web tech.

Another Flashy thing is Webnote. I've set up a space for Double Loop, with a topic in tool use in Project Management for us to try. This is sooo simple (emulated stickies) yet potentially powerful. Please, get involved at Loop2, Surface1, or use its XML feed to keep in touch.

And finally, Basecamp is a web-service oriented towards project management. Rather than produce scientifically intense charts and diagrams, it focusses on making communication between collaborators and clients easy, coupled with deadline-sensitive displays. Certainly easy to jump on if you know blogs - its spools projects out to RSS feeds and everything. Cheap too, if you compare it to hulks like Project, which if truth be known tend to paralyse the analysts and isolate the manager.

Now, off you go to Loop2Surface1. I'll buy you a drink if you correct my spelling mistakes, two if you add a Note that kicks the topic.

Large construction

Large construction,
originally uploaded by Drift Words.

or small construction? Smashy or Nicey?

Sometimes, our PM students don't quite get it. "Why are we playing with kids' toys?" Others just get on with it. Warming up the brain is a key element of this game, regardless of the PM lessons. We like this game, despite all the yelling we have to do.

Here, however, I'd like to point out that the Risk v Scope dilemma is plain to see.