Blog: Dan E. Linstedt

« Secrets of the Masters - Part 1 | Main | Part 3: Secrets of the Masters »

Part 2: Secrets of the Masters

With these posts I hope to shed some light on what makes projects work, no matter the scale, no matter the time-line; always with an eye on costs, overhead, and a watch on the number of errors. In part 1 of this series I introduced top-level concepts required by nearly all "good" projects. In this entry I will dive a little deeper into what these concepts bring to the table, and also add some lower-level concepts that are also necessary in successful projects. I'm specifically targeting 2nd generation warehouses, and DW2.0 - in an effort to move forward.

In the last post we discussed the following ideas:

1. Singularity
2. Repeatability and Standardization
3. Measurable
4. Automatable

Lest we forget it's always about:
1. People - AKA: Organizational Breakdown Structure (OBS)
2. Process - Process Breakdown Structure (PBS)
3. Data - Data Breakdown Structure (DBS)
4. Work - Work Breakdown Structure (WBS)

We need to apply the concepts:
1. Accountability
2. Version Control
3. Governance

To everything we build, be it a warehouse, a staging table, or a single star schema. Without these fundamental tenants, we have a difficult time reaching the top 4 goals listed above (defined in part 1).

What does this mean in real terms?
a. Everything must be numbered, and versioned. Use technical numbering patterns for extensibility and hierarchical concept organization
b. Glossaries must be developed and maintained, common terminology is extremely important.
c. Common check/in and check/out procedures must be applied to ALL project documentation, no longer is it acceptable to keep a spreadsheet, project plan, or requirements document out of site, or on a single persons' PC/desktop. It needs to be available in a common shared repository by the entire team.
d. AS-IS diagrams, documents, statements, use-cases are just as important as TO-BE defining where they need to go. Gap Analysis is a critical part of the success to any project. Without Gap Analysis, it becomes difficult to MEASURE the LOE (level of effort) to get from point A (as-is) to point B (to-be).
e. ALL BREAK-DOWN STRUCTURES SHOULD BE NUMBERED! And attached to line-items in the project plan, as I've blogged about in the past, and will bring back again shortly.

If you can, or if you remember how to: apply function points. The secret number is the number of person-hours per function point. Usually for the average "already trained" I.T. employee, it's roughly 1.5 person-hours per function point. Divide the function points in to groups: easy, moderate, difficult. However, don't change the hours per function point. Why? the resource expertise leveling will do this for you.

Divide the resources into "expert, knowledgeable, and beginner". Assign risk categories to each level of resource. Then assign a multiplier to each resource group, the lower the group knowledge, the higher the risk, also - the more person-hours per function point it will take. Ideally you want each person on the project resource weighted. Now, keep in mind that these are NOT general categories for resources. Each resource may be expert in a different category. Where do you get the categories from? The Work Breakdown Structure.

Ok, so you're beginning to get the point. You need a matrix to cross-reference all this information, yes.. Start with a solid project plan, where the numbers in the project plan are numbered down to EACH element and EACH paragraph, or better yet - specific sentences in the requirements document that tie a project plan line-item to the requirements. THEN cross the project plan numbers to a work breakdown structure, by using this strategy, you can "resource load" your project plan with roles and responsibilities (held in the WBS).

Once you assign resources, you can setup risk leveling for each line-item in the project plan, and tie them to difficulty counts in the function point analysis (task overview). But I get ahead of myself.

Proceed at once to the AS-IS documentation:
a) AS-IS data models
b) AS-IS process flows
c) AS-IS resource allocations
d) AS-IS results (that the business is receiving)

Then, proceed to define the TO-BE:
a) TO-BE data models (tie these back to the results, by project plan by number)
b) TO-BE process flows (tie these back to the results, by project plan by number)
c) TO-BE resource allocations (if the team assignments are to change)
d) TO-BE results (this ties directly BACK to the requirements document and project plan by number)

Then, assess the Gap between the two, and generate a risk assessment complete with analysis and documentation, necessary people, roles, knowledge, and data. Then, assign importance to each item in the risk assessment, and tie the results of the risk assessment back to the project plan, again by number.

What we are doing is crossing the PBS, DBS, WBS, and OBS together with the gap analysis, requirements document, and project plan. So we can clearly see _exactly_ what it takes to get from A to B in the shortest time possible. We are also clearly illuminating any obstacles in the way, be it training, to hardware, to software to make it happen. We can then MEASURE our progress as we begin down the project plan.

Now, we are taking charge and governing our build process for EDW/DW2.0 - once we begin this effort, the business will begin to take us seriously, and see that we too are accountable for our delivery efforts - and every step of the way they can monitor the progress.

Thoughts? What have you experienced? Have you executed function points? (yes they're from the 1970's but they still work when done properly).

Thanks,
Dan Linstedt

Share: