Dec 28 2010
After months or even years of hard work on a project, it is often easy to forget the final push into a production environment. After all the investment of time and effort that goes in to an IT project, having the project considered a failure due to a poor or failed implementation is not acceptable. The good news is that this risk can be mitigated by creating an hour by hour or even minute by minute implementation plan.
Dec 09 2010
This is a repost of the attached article first published in the PMI Virtual Library.
In the consulting world, project estimation is a critical component required for the delivery of a successful project. If you estimate correctly, you will deliver a project on time and within budget; get it wrong and you could end up over budget, with an unhappy client and a burned out team. Project estimation for business intelligence and data integration projects is especially difficult, given the number of stakeholders involved across the organization as well as the unknowns of data complexity and quality. Add to this mix a firm fixed price RFP (request for proposal) response for a client your organization has not done work for and you have the perfect climate for a poor estimate. In this article, I share my thoughts about the best way to approach a project estimate for an extract, transform load (ETL) project.
Dec 07 2010
When it comes to metaprogramming, even the most technical folks can find their eyes rolling back into their heads. I’ll admit, with all of the fun and new technologies out there, a discussion about metaprogramming is, in the name of brutal honesty, just outright boring… but, so is being addicted to brute force.
During a recent ETL implementation using T-SQL, changes in architecture and scope began to threaten the project’s delivery dates. I desperately wanted to begin development but feared throw away work resulting from requirement changes coming out of ongoing design and analysis discussions. How do you develop code without a finalized set of requirements and prevent re-writing each piece of code when requirements change?
Dec 06 2010
As most people know, to sprint means to move as fast as possible, typically for a short distance. Elite runners may sprint 400 meters. Marathon runners will sprint, but certainly not over the whole 26.2 mile race. Even NASCAR’s Sprint Cup cars do not red-line their engines for an entire race even though the cars are completely rebuilt between each race.
My point deals with the Agile Methodology’s (http://agilemethodology.org/) misuse of the term “sprint”. In the Agile world, a sprint is an incremental piece of work. Who really believes that eighth consecutive sprint enables an Agile project to move as fast as possible? Despite the obvious answer to that question, I do not expect to redefine decades old Agile terms. I would simply like to share some practical advice on dealing with those everlasting project milestones.
Dec 01 2010
White Paper – Enterprise Search of Leading Software Vendors
In order to help our clients and the industry learn about practical deployments, CapTech constantly evaluates how these solutions are working in the field. We have recently published Enterprise Search of Leading Software Vendors see below to download the White Paper.
2010 is a transition year for many of our clients. As they grapple with a slow economy, many are finally starting to realize that they need to get more assertive about improving their own prospects and start searching for growth opportunities. To accomplish this, many companies are very focused on harnessing their data and sharing the data with their management team. But how do they find it? What tools and process do they use?