Many see IT as application of technology to solve business problems.
Of course, this is true but it leaves out the third element, which is to apply the right architectural pattern to solve the problem. For example, when the business problem is that reporting is slow and reports from different departments don’t match, the astute IT professional immediately thinks in terms of a data warehousing pattern employing technologies like databases, extract-transform-load (ETL) tools, and multi-dimensional reporting suites. Continue reading →
A recurring theme in the literature on IT over the years has been frequent failure of IT projects. Most studies lay the bulk of the blame on requirements (examples here and here). One way to improve accuracy and fit-to-purpose of requirements, and thereby promote project success, is to include data analysis as well as process analysis in the requirements plan.
I’ve cited here the need to start data interface analysis early to avoid budget and schedule blow-ups when, as a result of not thinking early about interface complexity, data integration work turns out to be bigger and nastier than anticipated. Continue reading →
In a recent very thoughtful post on data quality, Paul Erb plays out an analogy comparing data users with Don Quixote and data quality professionals with Sancho Panza, then reverses the analogy to cleverly coin the “Sancho Panza” test of data quality professionals. He encourages data quality professionals promoting the critical role of data quality to apply a what would Sancho say test to ensure that they are aligned with the needs and interests of data consumers. Continue reading →
In a new post at Insurance Networking News Ara Trembly provides a balanced perspective on IT/business misalignment (Business/IT Misalignment: Whose Responsibility?). He describes the problem as cultural, more amenable to relational than management solutions. His conclusion sums it up: “Take a geek/suit to lunch today!”
To me (speaking as an IT professional) IT should take the initiative to solve the problem. Continue reading →
History is littered with IT application projects that end late, go way over budget, or abandoned altogether. I was fortunate enough to see one work out really well (almost – please read on). It was no mistake. It came down to a simple method advocated by a gentleman named named John Carpenter.
The project was an HR management software conversion from one commercial off-the-shelf software (COTS) package to another. The company concerned was conservative about spending money. A previous business case had proposed a similar project. The problem with that business case was that the benefits were really tough to conceptualize, so the cost/benefit analysis relied on soft benefits like “improved access to information” and “more consistent reporting data”. The folklore was that the CFO had physically thrown that business case out of his office. Continue reading →
Recently I was asked for a high level requirements plan for a large IT conversion. I googled around a little for something standard. I found some good references (see links at the bottom of this post), but not exactly what I was looking for: a simple, method-agnostic layout of the high level steps and checkpoints in requirements for a big project, emphasizing interactions with business people. I then rifled my files to find the example below. Continue reading →