«    »

ICE Conference Highlights

I recently attended two seminars at the ICE 2006 Technology Conference in Edmonton thanks to my employer CGI. I enjoyed both presentations and regret not attending more. I was able to pull some useful tips and ideas from each seminar that resonated with me.

The first session was Lessons for Risk Management Taken from the Titanic, presented by Mark Kozak-Holland. I really enjoyed his use of the story of the Titanic as a case study to relate to modern IT projects. Mark talked about a variety of project management issues and not just risk management as the title suggested. Some of his most noteworthy points were:

  • When do projects really finish? Most software development projects are considered complete when the software is deployed into production, if not earlier. Mark argued, and I agree, that the solution should be operational in production for a period of time for the project to be considered done. For the project to be considered a true success, the key return-on-investment metrics that drove the project should be measured to demonstrate that the original purpose of the project was achieved.
  • There are three different phases of a project when failures can happen: during the development, during implementation, and during operation. The later the phase, the more costly the failure. The key to successful operation is to ensure that non-functional requirements such as maintainability, performance, security, manageability, etc. get the same focus during development and testing as the functional requirements. Most executives and business representatives understand the functional requirements, but seldom understand the non-functional requirements, so there is a natural tendency for them to be neglected - either cut from the project scope, or not sufficiently tested. Mark pointed out that it is often much easier to add on functional requirements than non-functional requirements, and emphasized that project managers and architects should push back when the sponsors or business makes decisions that would compromise the solution.

The second session was The Role of the Enterprise Architect, presented by Jason Uppal. I have had conflicting opinions regarding the work and value of architects, so it was refreshing to hear Jason present a very pragmatic and reasonable viewpoint of enterprise architects. Some of the points that I liked were:

  • Enterprise architecture starts with a vision - is this project / solution the right thing to do? Jason had a great example of an architecture review he did of a overdue project. He determined that the original business goal of the project had been to improve the functionality and performance of a set of business reports. But the actual project being delivered was to migrate the mainframe application to a more modern web-based application.
  • Jason had an interesting rule of thumb regarding the problem statement provided by a client: shorter is better. A one sentence problem statement is ideal, while a multi-page document spells doom for the project. Why? The longer the problem statement, the more the client is specifying the solution they think they want, rather than specifying the actual problem. The more the client specifies the solution, the less they make use of the expertise of the architect in determining the solution.
  • Jason made an interesting point regarding project cancellation: it should be considered operational learning rather than a failure. One of the responsibilities of the architect is to determine whether the project makes sense. If it doesn't, it should be killed - the earlier the better.
  • Architects should never be the cause of project delays. Each architectural iteration should be one to two weeks in length. Each iteration elaborates on what was produced before and leaves fewer unanswered questions.
  • Architects should not have assumptions in their work. Instead, any assumptions should be treated and identified as risks. This allows for risk management strategies - i.e. risk mitigation - to plan for the risk if it occurs.

If you find this article helpful, please make a donation.

«    »