Watch this space: I’m writing AGAIN!!!

I just want you all to know that I have started writing again. Recently, I have spent a lot of time NOT writing (did have some other things to take care of, and still do), but it appears I have the bug again!

So, I want to let all of you, my readers, know that I am starting again with new materials AND I also want you to know that I have several blogs I am writing on:

Project Management Handbook:

BG Opinions:

Sixty Somethin:

Please check these out and I hope that you continue to enjoy reading, and please send me your comments or suggestions at or some of my other email addresses for these blogs.

Thanx, bgbg

On Conceptual Modeling: 1984; Brodie, Mylopolous, Schmidt

From a recent review of this book (see Blog Post Title), I have a question:

Main Question:  Is it more efficient to build the indexes in support of invisible keys or to store this same data in each row of a set of tables?

What is an Invisible Key?

A row of data must have fields included that uniquely identify each individual row.  For example, a row in a “Person” data object will be identified by some combination of fields containing: Name, Tax identifier, Country of Origin, Birth Date, etc.  No one of these data fields would be enough to uniquely identify each “Person” in the object, but a combination will usually work well.

Each of these fields has a certain specific size or number of characters allowed at a maximum or absolute size: Birth Date could be represented by the following data pattern: yyyymmdd; whereas the Tax Identifier could be different sizes depending on the Country of Origin.

The notion of Invisible Key is that even though these data fields are used to uniquely identify each row in an object, the specific data values for each row of data, the birth date field, do not have to be physically present in the row in order to find it in a search or inquiry.  As a simple example, let’s use the Birth Date field to describe how this is possible.

The date field, as described above, has 8 characters in it which we should agree can identify each and every Birth Date for the foreseeable past and future.  This statement should be true from January 1, 0000 through and including December 31, 9999.  The dates prior to the first recordable year would need another representation that we will not include in these discussions.  And, the dates beyond December 31, 9999 will need a conversion/expansion similar to the Y2K efforts which some of us may remember.

The allowable values in each of the characters in our Birth Date field are limited to a range of numbers from Zero (0) to Nine (9) only.  If we were to build a data base that would maintain an individual index for each of these data characters so that each of these indices has a list of all data rows that have a Zero in position one, One in position one, Two in position one, etc. through Nine in position one; and repeat these lists for each position in our data field: Position One through Eight, then we can select the lists of indices that we will want to look for in a search:

  • Year 2010 will use a search for:
    • All records where Birth Date Year Position One equals “2”
      and Birth Date Year Position Two equals “0”
      and Birth Date Year Position Three equals “1”
      and Birth Date Year Position Four equals “0”
    • The result of this search will be a list of all record locations that contain 2010 in the “year” portion of the Birth Date!

Using this type of inverted list index, we can extract any Birth Date or range of Birth Dates based on the content and record locations in the Indices rather than requiring that that same content be present in each row of data!

As far as the original question, I would like to know how much space would be required to maintain the List Indices for all these data positions versus how much space will be required to maintain these same data in both an index structure AND the data rows themselves.

If we take the inventory of fields proposed earlier and guess at their physical sizes then each row of data represents (and could contain) the following number of characters:

  • Last Name                   Char (25)
  • Middle Name                Char (15)
  • First Name                   Char (15)
  • Country of Origin         Char (25)
  • Tax Identifier               Char (15)
  • Birth Date                    Char (8)

For a total number of positions of: 103 characters.

Multiplying this number of positions by the number of “People” in our data collection could be a staggering sum of physical space in a data object.  For example, ten thousand (10,000) people in an “Employee” data base would require over One Million (1,030,000) characters.  That may not be a ‘staggering’ number but what if we are talking about the “person” data for an Electronic Medical Records data object servicing a National or Global Health Care application?  Three hundred billion people (300,000,000,000) would require almost 31 Giga Bytes (30,900,000,000,000 characters)!  And, this is just for the data values that might need to be indexed.

So what would it take in physical space to represent the indices for these same data fields/values?

The simple truth about THAT is that I don’t know enough about physically building indices to answer THAT question.  Can you?  Please?

The answer to this question, in my opinion, can have a significant effect on the approach and the ability of the technical community to respond to the organizational demands for an ever increasing amount of data for their analytical needs.

“I’m just asking…”

Hello World! Thank You, World!

I’ve been writing random and sometimes organized thoughts in this blog for quite a while now and I just took a closer look at the statistics of people who have read my stuff.

So, I want to Thank every one of you who have read my materials and I hope that you all continue to take benefit from or enjoy these materials.

Here is a graphic of the geographical reach that I have benefited from and I would like each of you to know that I appreciate every minute you take to follow me, read this stuff, and, hopefully comment on and invite others you know to read this same information:


Thank you, bgbg

The Data Manifesto

All Data Are Protected (ala The Matrix)

An Event occurs that is associated with a collection of data attributes that need protection.

Each unique Event has a finite list of Data that are expected to occur when a new instance of an Event happens.  In almost all cases, that list of Data includes, at least, the Date, Time, Location, and Instigator of the Event.  Other Data are also needed depending on the specific Type or Name of each Event.  This list of proscribed Data for a unique Event is called a Row.  When each Row first expresses as an Event it is considered an Unprotected Row.

Event Data requires that it receive protection before becoming in three levels:

  1. Content Protection
  2. Field Relationship Protection
  3. Object Relationship Protection

Once a set of Event Data or each Unprotected Row passes all three of these levels, it can become a legitimate Transaction and take its place in its Legitimate Protected Transaction Row Object to be processed against its Master Data Object(s).

Protection Level One: Content

Each Data has a pre-determined set of Valid Values that are anticipated and allowed in that Data.  If a Data contains Value that is not in the anticipated Valid Value set, then the Unprotected Row that represents this particular Event is sent to “Corrections” for further processing.  This set of Event Data CANNOT be processed as a Level One Unprotected Row.

Further, each Unprotected Row for a unique Event will have Data that are defined as Primary and/or Partial Key Data which is used to uniquely identify each instance of every Event occurrence.

Valid Unprotected Rows that pass this Level One Protection can proceed to Level Two Protection validation.

Protection Level Two: Field Relationship

Some Data have Values that require or limit the selection of Valid Values for other Data in its Unprotected Row.  If a Data Value prescribes that other Data be limited to a subset of their anticipated Valid Values then those Data must be validated based on that limited subset.

If a related Data does not comply with its limited Valid Value set, then the Unprotected Row that represents this particular Event is sent to “Corrections” for further processing.  This set of Event Data CANNOT be processed as a Level Two Unprotected Row.

Valid Unprotected Rows that pass this Level Two Protection can proceed to Level Three Protection Validation.

Protection Level Three: Object Relationship

Successful Level One and Level Two Unprotected Rows must have Relationships with other Objects in the Model by using the Valid Values that are in their Data that are part of their Primary or Partial Key Data.  The Values in these Primary and/or Partial Key Data have specific Relationship Rules to other named Objects that must be Validated.

Optional Relationship Rules need NOT be Validated.

The Relationships that are marked as Mandatory MUST find Protected Rows in named Objects elsewhere in the Model.  If these Mandatory Relationships are not proven to exist then the Unprotected Row is sent to “Corrections” for further processing.  This set of Event Data CANNOT be processed as a Legitimate Protected Transaction.

Valid Unprotected Rows that pass this Level Three Protection will be inserted in the Legitimate Protected Transaction Row Object that this Type of Event is assigned to for further processing.

All Data Are Protected.

Standards for Cloud Computing

I believe things get “REAL” when there are standards and guidelines for those practitioners who are interested in moving things forward.

I found this article talking about creating standards for Cloud Computing and I agree whole-heartedly!

Thanx for reading and enjoy the article.

If you can, be prepared to join the debate.


Swim Lane Diagrams

Since when did Swim Lane Diagrams take the place of more rigorous Software Engineering Requirements gathering models like: Process Models, Data Relationship Models, State Transition Diagrams, Use Cases and Event Models?

I’ve been managing several smaller projects lately and if they have any kind of Analysis efforts and documented Requirements, they are only represented in Swim Lane diagrams that are syntactically broken!  And, do not have any written or graphic supporting materials to explain any of the intent of these Swim Lanes.

How can ONE diagram be a defensible proof that we have investigated all perspectives of a proposed solution and that we have proven to ourselves, with some level of reliability, that we have a complete and cohesive solution?  I, for one, think that we CAN’T!

Ed.  I’ve just started on this line of thought and will have more shortly.  bgbg

Turn the Organization Upside Down!

Similar to the notion of “Servant Leadership”, I suggest we look at an Organization from a perspective that is different than the way many organizations will present the Organization Chart: CEO / Owner / Organizational Leader down thru levels of management to as many levels of workers as they choose to include in the org chart.

Instead, I suggest we start from a viewpoint that is NOT on the Org chart: the Stock Holders or other external beneficiaries and make sure we understand that each organization is put in place to succeed FOR these Stock Holders and / or other external beneficiaries.

Certainly the Customer should also be involved in this opening perspective on an Organization because without the consumers of whatever product or service each organization is offering to its customer base, there would be NO Organization.  AND, without satisfied customers there would be very little reason for Stock Holders to invest their time, money, interest, and support in our organization.

So, the next time one of your bosses tells you that you need to get something done because “I said so!”, think about how you could 1) Keep your job; and 2) Turn your bosses perspective Upside Down!


Starting your own PMO

If your organization does not have a PMO or has one that has been disappointing in its benefits, then this discussion may be for you!

I have an opinion that there are “Five ‘P’s in PMO”: Project, Program, Portfolio, Process, and People.  Others don’t necessarily agree with me but then they are not writing THIS article, are they!?!

In order to get a successful PMO started, an organization needs to conduct the initiation effort like a project:

  • Investigate and understand the differences between the three basic PMO types that are typically used in organizations: Project, Program, and Portfolio
  • Recognize that most initial PMO efforts will have to address these three levels of PMO in some small way so that whichever one is MOST important to you can be properly supported
  • Develop a Charter and a Budget based on your initial expectations for your PMO
  • Establish a Schedule for preparing new Standards, Techniques, Measurements, and Metrics that you can envision as your starting Guidelines for each of the PMO types
  • Manage your own expectations so that all contributors realize that you should expect to create ONE new standard and associated materials to be implemented at a time and monitor its effectiveness before you proceed with any subsequent PMO standard.  This, after all, is your latest (or FIRST) time in trying to implement a potentially complex management structure within your organization which hasn’t seen the need for one for some time!

Let’s say that your management agrees that it would like to start simple with a Project Management Office to set Execution standards for the performance of each project undertaken within either the entire organization or just the Information Technology department or function in your company.

Why, then, have I said that you should expect to have some portions of Program and Portfolio Management Offices included in your first planned implementation?

A Portfolio Management Office is created in organizations to collect, prioritize, and select requested expenditures as projects based on their relevance to the organizations Strategic plans and Tactical needs.  If your organization does not have a back log of requested project expenditures, then maybe you don’t actually need this structure.  However, I doubt that many companies have no backlog and those that say they don’t may just not be looking in the right places to find these requests.

At least, create an official company spreadsheet of the unapproved requested project expenditures so that you can review the list and determine if there are one or two that are higher priority than the rest of the list based on your hoped for corporate directions.

A Program Management Office is created to oversee the execution of a series of projects that are co-dependent with each other and are supportive of a larger organization goal where each project may have deliverables that other dependent projects are waiting for at some point during their execution.  The standards that would be prepared in a Program Management Office will monitor these interdependencies and give opportunity for the various Project Leaders and their Managing Sponsors to know the status of the co-dependent materials.

So, creating a list of Projects that are related to a larger scale business need AND identifying the dependencies that each of these projects have on others that are or will be executed, will allow you and your management to be aware of these interdependencies so that when something goes wrong with one project and its results are needed by some other project, you can make better decisions about how to respond.

Project in Recovery (not THAT Recovery!)

When a project has been close to failure and shut down is not an option then my repetitive approach to resolving the remaining issues usually goes something like this:

  1. Agree on the Recovery Project Charter
    1. Scope
    2. Objectives
    3. Budget
    4. Staff
    5. List of Open Risks, Issues, Change Request
      (preferably these lists will be placed in Recovery Project Priority Sequence as part of producing the Charter)

The approach I have taken once we get agreement on the Charter is very tactical and focused on only a few possible activities and outcomes.  It’s simplistic but has been very effective for me in the past.

Create a Daily Punch List that starts with an early morning meeting of all contributors to the Execution of the project.  This should include representation from the Executive, Business, and Technical teams.

The agenda for this meeting is fairly simple:

  • Review the open list of the highest priority Issues and Change Requests that remain unresolved
    • On Day One, this will require that the team spend the appropriate time to establish this Priority sequence if it has not already been done as part of the Charter.
  • Determine the current status of the highest priority items and agree that:
    • Progress has been made
    • The Priorities have not changed to some other items that are lower on the list
  • Discuss the as yet inactive items on Issues and Change Requests to determine an agreeable combination of the following:
    • Priority – on an appropriate scale with clear definitions of what each level means and how each item qualifies for that level
    • Outcome – determine one of THREE possible outcomes for each item:
      • People – The person or group who represent each item may need to be informed of some capability of the solution as already built that can address their issue without making any changes to the proposed solution.  This could mean that education, training, and demonstrations are needed to convince the submitter(s) / owners of each item that they were unaware of the already built and tested capabilities of the proposed solution.
      • Process – The processes and integration points into and out of the proposed solution need to be changed so that the capabilities of the automated part of the proposed solution can address each item.  This could mean that although the automated solution is capable of resolving the item, the data preparation and usage around the solution was not sufficient to allow these features to be shown.
      • Product – The proposed solution, whether it is an in-house developed solution, a pre-packaged and configurable licensable software product, or a combination of cloud and internet features and custom programming, does not have the capability to address each item and, therefore, must be changed.  This could have been caused by unclear Requirements and Specifications; misinterpreting some Requirements into Specifications and / or code, or missing some Requirements entirely.This Outcome will often require that additional planning and funding be provided before the change / fix can be staffed and implemented.

If one early morning meeting does not provide the time to go through the entire open item list (Risks, Issues, and Change Requests), then more brief meetings should be scheduled each day until the entire list can be handled in ONE Meeting!

Ultimately, these lists should show progress of being reduced on a Daily Basis with a predictable schedule so that the newly Planned Completion Date for the Recover Project becomes measurably achievable.

Thanx, bgbg

Project in Trouble?

Despite all of our best efforts, some projects end up in trouble and they need to be ‘saved’ or ‘shut down’!

Making the ‘shut down’ decision is very difficult but must be considered once a project that is in trouble is identified.  Some of the questions I have used in the past to determine whether a project is salvageable or not are:

  • How much of the currently approved Project Budget is still available to spend?
  • What do the Project Sponsors think went wrong and are they supportive of the effort that may be required to save this one?
    • This will play into the answer about the remaining budget and whether the Business Sponsors are willing to provide additional funding when needed!
    • Will the Recovery effort impact other planned and / or active projects that have a comparatively higher priority?
    • Is the Scope of the project still representative of the Business need that justified the project and its changes to date?
    • Are there known Risks, Issues, and Open Changes that Executive Management, the Business Sponsors, and the Technical Management and staff agree are representative and complete regarding the things that need to be fixed so that the project can be  turned into a success (or at least not a grave failure)?
    • How many of the people and resources that are assigned to the project can remain on the project while we try to salvage it?
    • How many of the people who are or were assigned to this project should NOT be on the ‘salvage’ team and WHY?
      • If some of the project people are negative about the project and its prospects for recovery, they may not be the best people to have work on the salvage team.

If a “Project Recovery Assessment Team” can agree that the answers to these questions regarding this particular project are supportive of a “Salvage Attempt”, then the Executive Management, Business Sponsors, and Technical Management must agree on a Project Charter for this recover effort and prioritize it with other efforts already in planning or underway.

See my post on “Project In Recovery”:

Project in Recovery (not THAT Recovery!)

With this agreement, the planning and execution of the project salvaging effort can begin.  If not, then sometimes “You have to shoot your own dog!” as a very wise person once wrote!

%d bloggers like this: