Virtually all IT projects of even marginal significance that Iíve worked over the years share, to a greater or lesser extent, the following characteristics:
These challenges are nasty, and the usual mix of IT frameworks and methodologies do little to address them. As the saying goes, technology is easy - people aren't. A lot of what follows comes from a desire to deal with these challenges.
This model is not a methodology or a framework. It is not prescriptive, in that specific tasks don't have to be completed in sequence, nor does any task need to be completed at all. There's nothing inherently new here, either. It's been assembled from observation, management consulting practices, books I've read, and things I've learned from others.
It's a collection of techniques that have consistently worked. While aimed squarely at architects, it applies as much to the corporate IT world as it does to a one-person startup. View the model as guidance, and a checklist.
Finally, it's a work in progress. I will add to it as time permits, and change it as I learn.
I'm an architect, so I drew a picture:
The model puts human engineering front and centre, because how a project starts sets the tone for how it ends. Understanding the situation (the current state) provides an understanding of your clientís process and technology landscape. What it's really doing though, is getting the architect in front of stakeholders and, through kick-off meetings, workshops and interviews, it is building relationships, and establishing trust and credibility.
This makes the situational analysis the single most important task in a new project - it drives the objective, scope, and ultimately a successful solution.
Change is constant, so the situational analysis is revised continuously throughout the project to pre-empt suprises. Change is driven down through the objective and scope to the solution. Risk is managed throughout, as are the relationships with stakeholders first established at the start.
The model consists of 6 concurrent and on-going tasks, and a closing task:
Understand the transformation (one or more processes) the client seeks to address, and find out what the technology landscape looks like. While you're doing that, start identifying stakeholders, and familiarise yourself with the client's worldview, environment, and the power and political landscape.
Identify who the client is, and define the client's objective. The objective is specific, measurable, agreed to by the client, realistic, and time-boxed. It is guided by the results of the situational analysis.
Bound the solution by outlining it's features and functions, by defining what's out of scope, and by discussing the criteria by which success is measured. The scope delineates what stakeholders expect the project to deliver.
This is where the solution is built. It is informed by each of the other 5 tasks. Design and Build makes use of good practices and if necessary, a suitable approach to developing software like waterfall, spiral or scrum. The choice of methdology is determined in part by the client's worldview, uncovered in the situational analysis.
The process of identifying, analysing, planning and tracking risk to reduce the probability and severity of loss.
This is about maintaining the relationships first established during the situational analysis, and managing expectations.
The post-project analysis is a summary of the good, the bad and the ugly, and adds to the knowledge base of lessons learned.
This model adresses the biggest single gap in existing approaches to IT projects - it puts people first. It does not seek to replace existing IT frameworks and methodologies - merely to augment them.