Category: methodology

Project 21 not dead just resting!

I’ve been a bit too busy to get around to Project 21 lately, but I will get around to it. I’ve been working on my own web site at http://www.mikeallen.com.au and other projects. I intend to get back to methodology as soon as I can. My next update will begin to integrate the Business Motivation Model(BMM) into my ideas. I’ve had a bit of an epiphany about functional and non-functional requirements and I need to work it through in the BMM context. I think the functional/non-functional divide, while useful, can be considerably improved on by using the BMM. The BMM has enormous potential to change the way we think about business and technology and can enable us to fully integrate technology into the business plan. This can create a real Win-Win scenario where business can clearly associate technology with business needs and technologists can link their solutions directly to the business plan.

Watch this space for more updates real soon!

Update to Interfaces

I’ve completed an update of the Logical Design of Interfaces, human interfaces that is, and I’ve found a fertile area for more visualizations of the way that people can interact with the system. This connect very well with Use Cases, which looks like it will be the next area for an upgrade. The division of the development phases of the methodology into the User Interface, Process and Data streams is not meant to define separation but more aspects of development that complement each other in the completed solution. I say this because I don’t see the methodology as rubber stamping three-tier development, which was a good approach for traditional client server, but was never meant to be the ideology that some people make it into.

If there is any ideology in this methodology it is the ideology of ‘connectedness’, that no aspect of a system can be viewed in isolation and out of context. The useful synthesis of ideas and visulizations with business process and data should be apparent in the user interface and how people interact with that interface.

Is this an Agile methodology?

Working on the design process makes me think that Project 21 sometimes looks like Agile and sometimes not, depending on which stage it is at. Considering the Agile and the Business Analyst are often at odds, this seems to be perfectly normal. Just by trying to separate the analysis of the problem from the design of the solution exposes the Agile dichotomy; is it possible to design a solution without analyzing the problem? The answer must be a definite maybe, but for any non-trivial problem analysis and design are needed to ensure that the solution solves the problem. Project management methodologies tend to go around this issue by being prescriptive about eliciting requirements and signing off, yet Agile addresses the issue of the requirement developing with the solution.

To a degree both approaches have their merits, if the user can state business requirements at a high level these can be quantified in the development cycle. The design phase can say ‘we address these broad requirements’, and development can refine the detailed requirement. I’m not going to brand Project 21 as purely an Agile methodology, it is an adaptable methodology.

Navigation Updates and Methodology Blogging

I’ve noticed that I’m not getting a lot of navigation between pages so I’ve started puting some navigation links in the appropriate places, so that people aren’t relying on ‘Contents’ for navigation but can go straight to Project 21 pages via hyperlinks where the page is referenced. I’m still mulling whether I need page navigation with a ‘next’ and ‘previous’ and ‘up’ context. I’m back on content this week and working on the heartland of logical design, hope to publish and blog a bit more by next week. Teasing apart Analysis and Design is quite interesting, I think the pressures of teaching mean that most I.T. people see it as a single process. Business people on the other hand want to skip analysis and design completely and go stright to the solution! Maybe I’m generalizing too much, but ther’s no doubt of the popularity of single stage development, where the user dictates requirements and the programmer creates the solution. Single stage development can work in some instances but falls over in the face of complexity, which is why I’m pitching my methodology in that nice sunny spot between the rapids of Agile and the mythical Waterfall.

Logical Design – at the workface

I’ve just put the Logical Design page up, and I seem to need more content, so it’s back to the writing desk to create this bit. This will be interesting as I try to describe what is often a very dynamic process in words that other people can understand. I’ll set myself a target of Friday and get started. This may be the start a a slightly more formal approach as it involves ‘Use Cases’.

Moving to the Development Phase

Building up the pages, and getting the pages happening as I want them to be, has been a challenge and a good learning experience. But now I have put up the first page of the Development Phase of the methodology, and realize that web publication has moved into the development phase. The next ten or so pages detailing development will happen over the next week and then I can return to writing the methodology. I see the current work as being ‘Chapter 1’ a freestanding summary methodology, the next chapter will be on the governance stream of the methodology. My current target is to finish ‘Chapter 1’ this month and then move on to the ‘stream chapters’. I have another sub-project which is ‘Project 21 – the software’ which is in the conceptual phase, I think some software to help implement the methodology might be a good thing.

A better way to manage projects

I’ve realised that maybe I could have started with the more exciting subjects like why do ‘IT Project always run over budget?’, but the answer to that lies in project methodology, and in the area of governance; I have to work my way towards it by laying the groundwork in place. The basic reasons are very simple, that project planning tools are not flexible enough to measure true progress and can only measure on and over budget activities. The only way that a project can be delivered on time using conventional project management software is to either have a grossly overestimated project or to finesse the cost codes once they have reached capacity, the truly creative manager will use both of these techniques and other methods of falsifying deliverables and costs so that the sun comes out. But is this really necessary? Can IT professionals predict what will happen on an IT project? The answer is yes, but must be qualified by good methodology and governance and recognizing that project outcomes deliver into a value range, not a value point. On the down side a lot of IT Managers enjoy the ‘mystical’ side of IT and are not into modern project management technique, not that ‘mystical’ management is purely the realm of IT.