Blog: Dan E. Linstedt

« New Skills Required - Interactive BI | Main | Dynamic Data Models - Automorphic Changes »

Part 6: Secrets of the Masters

To follow on with our series, we'll dive in now and explore some of the elements needed for a repeatable, consistent, and redundant project. These are components that make the project book completely usable - without these pieces, the project methodology usually sits on a shelf and gathers dust. What we are aiming at is: the hope of reducing overhead costs, reducing errors, increasing productivity, and increasing agility of I.T.

Welcome to the next entry in the series. In this entry we'll dive in to some of the physical components you want in your project binder to help make it work. Despite what some believe (that this is cumbersome, overly documented, pushed to the edge, too many standards) etc...

Once followed, it actually makes project work repeatable, consistent, and reliable. It puts you and your team in a position of continuous process improvement, and continuous success. There are a few key deliverables that absolutely must be put in to the project binder.

1) Service Level Agreements - SLA's. These are a phenomenal way to communicate acceptance of everything from default values to problems and issues that arise during project implementation. Without SLA's, the project can easily be "blamed" for not meeting goals, not building what was expected, not getting it right.

The hard part? Getting the business to realize that this doesn't mean "it's set in stone" - it simply means that they understand the level of service currently being implemented, and they agree with the output _at that time_. Once we've achieved this level of understanding, and teach the business that they can change their minds (by signing a new SLA) then we can take steps forward.

SLA's function as change requests, issues and mitigation choices, and implementation direction controls. Standard SLA's should be a part of every project, and should be carried around by the project lead in their back pocket.

They don't have to be long (usually not more than one paragraph) but they do need signature lines: Project manager, one of the sponsors, and a business technical lead.

2) Business Technical Lead. What is this? This role is usually assigned to someone on the business side of the house. Someone who then interfaces with the project manager in I.T. on a daily basis. They are business driven, but have a knack for I.T. and a deep understanding of how to work the technology. They are responsible for setting up all meetings with the business users, coordinating the rooms, writing the user help manual, generating the first cut of metadata and definitions, and being a part of the immediate "testing team" which provides results / runs reports against your production data.

They are the ones who call emergency meetings when a hard-stop is reached in the project. They also work in tandem with the business itself to ensure the project doesn't fall off-track, or off-focus. they communicate with the Project manager about pending business changes. These resources are invaluable. If you don't have one on your project, your likelihood of _long term_ success is limited.

3) Expert Knowledge. All too frequently consulting companies bring in the expert to help close the sale, I.T. departments are guilty of the SAME THING! Then, they wisk the expert away back to some production fire which is not the project at hand, never to be seen again. This doesn't work for successful projects. Successful projects _need_ the expert on a consistent basis, and if an expert isn't available locally - get one from outside. Hire one as a consultant, bring them in as a sub-contractor, etc.. Any way you can. These experts should have the following skill sets:
* Have handled large projects
* Have built (actually technically implemented hands-on) with large volumes of data (25 TB+)
* Have expertise in data mining, understanding of data patterns
* Have multi-database engine experience (not just a single database engine)
* Understand business requirements
* Have a grasp of _multiple_ ETL, and BI tool suites
* Have working knowledge of 3rd Normal Form, Data Vault Modeling, and Star Schemas
* Understand ODS, Stage, Data Warehouse, and Star Schemas
* Be able to articulate definitions of compliance, accountability and governance.

It's a plus if they've worked on real-time data warehouses, or have had government experience, and gained SEI/CMMI Level 3 experience.

4) Have a subject matter expert: a SME who's also well versed in Cobol (if there are Cobol sources to pull from). Someone who understands the business from a data and systems side. Someone who can help identify exactly what you have, and what you don't have available to source from, or target to. Someone who can identify the problems with the current source system, and share the existing change requests that the system is undergoing. This person should have daily interaction with the Operational Systems and the teams running those applications.

Ok, so in this entry I diverged a bit. I'll get back to the templates in the next entry in the series. In this entry I went back to rule #1: identify roles and responsibilities - these are key roles and responsibilities that make projects successful out of the gate. Even small projects at mom & pop shops, these roles and responsibilities are important.

Hope this helps,
Dan Linstedt
DanL@DanLinstedt.com

Share: