I'm pretty certain that most managers know what they are talking about most of the time, but, despite applying tools, techniques and frameworks diligently, still find themselves in trouble with their projects.
I happen to think that a big driver of project problems is not that tools are inadequate but that deep skill is needed to select the right ones for the circumstances. Methodologies and standard processes (such as PRINCE) assist by pre-selecting a range of tools, but success here depends on the conditions in the project at hand being consistent with the assumptions in the methodology.
Assuming that managers can compentently select appropriate control paradigms, awareness of the project environment and internal health is critical. Risk Awareness is one case in point, one that I think is undervalued at present, despite the apparent depth of numerical frameworks. I wrote about this before, showing my framework for the descision space of all projects.
Here's another project classification I like, since it focuses on the nature of uncertainties that may be met in a spectrum of projects.
On the use and abuse of Technology and its Management from the perspective of an academic at UCL specialising in Project Management, Systems Engineering and Space Science/Technology.
Monday, June 27, 2005
Tuesday, June 21, 2005
Link roundup
- Hilarious analogy by Richard Stallman between software and literature that shoots a torpedo at software patents.
- How management should be done:
There were no complicated negotiations between Worthy Farm and the Jaxx camp, adds Buxton. "They said: 'Do you want to move up the bill?' and we said: 'Yeah'."
Story. - What is Learning? by Albert Ip. That's a nice taxonomy you got there, Albert. Does it actually run?
- Interesting blog on, er, blogging. Specifically productive blogging ideas for all sorts of professions. Comes from James Farmer, who's been promoting innovative tools in education for a while, and has now branched into the so-called professional world.
Monday, June 13, 2005
On Being Dumped into an Existing Project
No link or anything, just some musings sparked off by what one of my students is about to embark upon, which chimed with some of my own experience. I found myself on both sides of the same knowledge divide at various times. First as the have-not, then as the have, or rather, once-had.
I asked my student if he had some headway with developing some descriptive models or frameworks for learning and knowledge processes? In truth, we are still looking for generic or well-worn models in this area.
I had some overlap with this topic, which sparked this post, when a colleague consulted me on a project she had become involved with. This is a data analysis and instrumentation calibration exercise that I had worked on some years before. It is one aspect of a larger system of instruments and spacecraft. We discussed what it was like to join a pre-existing technical community.
We both felt that the experience of climbing aboard an ongoing project is typically likely to have a confusing aspect. There might be several hundred documents (or software code examples) that serve as the reference literature, but it will not be clear to an outsider what the relationships between them are. Strategies to improve this might involve indexing or tagging/keywording collections of documents, or for a documentation writer to write meta-documentation that assumes particular specimem tasks, and guides the user through the documentation as much as the task itself.
Workers already on the team might be unable to articulate their knowledge in a way needed by the new arrival, especially if the newbie's question is regarded as trivial. A very advanced query might get rapt attention, on the other hand. This is a cultural and/or timescale issue.
Finding the right mentor is a crucial step - someone with the time to deal with enquiries, with sufficient expertise, and yet empathy for the learner's point of view.
Another strategy of acquiring knowledge is to proceed in chunks, studying some aspects of the functionality of the system in isolation.
As the learner grows in knowledge, one way that they deal with the confusion is start gathering references to the body of knowledge, and building a store of useful links - a subset of the entire content set.
Later, when they are able to describe their work process in relation to the existing system (which might be different from everyone else's process) it can be documented and added to the system archive. This documentation activity is a valuable learning tool for the author.
There are difficulties in ensuring that this new secondary knowledge does not itself become lost in the body of knowledge. In some cases there can be barriers to such publication or amendment of the archive (configuration management system?). Knowledge systems should have an alternate channel (preferally collaborative such as a wiki) or allow grades of control. If the quality system demands the perfect document it will never get written (and will hence cause product quality to suffer).
I asked my student if he had some headway with developing some descriptive models or frameworks for learning and knowledge processes? In truth, we are still looking for generic or well-worn models in this area.
I had some overlap with this topic, which sparked this post, when a colleague consulted me on a project she had become involved with. This is a data analysis and instrumentation calibration exercise that I had worked on some years before. It is one aspect of a larger system of instruments and spacecraft. We discussed what it was like to join a pre-existing technical community.
We both felt that the experience of climbing aboard an ongoing project is typically likely to have a confusing aspect. There might be several hundred documents (or software code examples) that serve as the reference literature, but it will not be clear to an outsider what the relationships between them are. Strategies to improve this might involve indexing or tagging/keywording collections of documents, or for a documentation writer to write meta-documentation that assumes particular specimem tasks, and guides the user through the documentation as much as the task itself.
Workers already on the team might be unable to articulate their knowledge in a way needed by the new arrival, especially if the newbie's question is regarded as trivial. A very advanced query might get rapt attention, on the other hand. This is a cultural and/or timescale issue.
Finding the right mentor is a crucial step - someone with the time to deal with enquiries, with sufficient expertise, and yet empathy for the learner's point of view.
Another strategy of acquiring knowledge is to proceed in chunks, studying some aspects of the functionality of the system in isolation.
As the learner grows in knowledge, one way that they deal with the confusion is start gathering references to the body of knowledge, and building a store of useful links - a subset of the entire content set.
Later, when they are able to describe their work process in relation to the existing system (which might be different from everyone else's process) it can be documented and added to the system archive. This documentation activity is a valuable learning tool for the author.
There are difficulties in ensuring that this new secondary knowledge does not itself become lost in the body of knowledge. In some cases there can be barriers to such publication or amendment of the archive (configuration management system?). Knowledge systems should have an alternate channel (preferally collaborative such as a wiki) or allow grades of control. If the quality system demands the perfect document it will never get written (and will hence cause product quality to suffer).
Subscribe to:
Posts (Atom)