Hello World! Thank You, World!

Tags

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

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:

Image

Thank you, bgbg

Advertisements

The Data Manifesto

Tags

, , , , , , , , , , , , , , , , , , , , , , , , , , , ,

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

Tags

, , , , , , , , , , , , , , , , , ,

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!

http://serion.co.nz/blog/hybrid-and-cloud-computing-standards

Thanx for reading and enjoy the article.

If you can, be prepared to join the debate.

bgbg

Swim Lane Diagrams

Tags

, , , , , , , , , , , , , , , , , , , , , , , ,

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!

Tags

, , , , , , , , , , , ,

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!

bgbg

Starting your own PMO

Tags

, , , , , , , , , , , , , , , , , ,

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!)

Tags

, , , , , , , , , , , , , , , , ,

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 submitters / 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?

Tags

, , , , , , , , ,

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.

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!

What do seven Y’s spell??

Tags

, , , , , , , , , , , ,

REQUIREMENTS! When someone tells you they have a need, you should be able to investigate that original statement with about seven (7) Why’s before they get bored or frustrated with your interest.

I need a daily spending report!

Why Daily? Why only spending? Why only ONE day? Why not a Rollling Daily Report of 5 – 7 days? Why not a Graphic representation? Why do we have to Print this? (Tired of asking yet?  You still have TWO more left!!!)

bgbg

What Users Say Translated to Software Engineering!

Tags

, , , , , , , , , , , , , ,

I need a report that shows me how much I spent yesterday!

Not an atypical ‘requirement’ from a business users’ point of view, huh?  What do you as a Software Engineer DO with this and similar statements?

Let’s start with a couple of questions that we can use to expand and clarify on a statement like this:

  • You SHOULD already know what business unit this user is in but if you are at all unsure, ASK!
  • You SHOULD already know what data this user’s business responsibility has access to but if are you unsure, ASK!
  • Are there other data fields that are important to the report being requested that are NOT within the reach of this Business User?
  • Are their calculations that are to be performed for this report and are the data required for these calculations currently available within the ‘reach’ of this report?

As a recap, the Business Unit and its accessible data will point you to a segment of the organization’s Entity Relationship Diagram (ERD).  This can act as an initial data context for these discussions.  If other data is needed for this report but is not within the organization’s data context, then you will need to inspect the rest of the Organization’s ERD to confirm that there is a usable path to get to this related data.  Once this path is confirmed as available, defined as a needed new path to existing data, or clearly identified as a new data point that has not yet been collected, we can add this to the Proposed Solution ERD.

The process of collecting the data together for the delivery of this report can then begin with the answers to a few other questions:

  • What business condition(s) should trigger the creation of this report?
    o   Frequency: Daily, Weekly, Monthly, Quarterly, Annual, etc.
    o   Number of transactions (since last report, or overall in increments, etc.)
    o   Data relationships indicating an situation: normal, abnormal, other
  • What conditions will affect when certain calculations are Needed or Not Available?
  • Where can new data be found and how should it be stored for use in this report?
  • What sequence or search criteria should be used to select data to be included in this report?
  • What changes should be made to the data to indicate that this report has been delivered for a certain date range, business condition, or other situation?

The process model can now be built as a Data Flow Diagram or Object Model with Methods to show the identification of the situation(s) that will trigger this report; the sequence of data collection and selection, the calculations that are to be included, and the production of the report.

The distribution of this report is still not determined but with just a few more questions, a Software Engineer should be able to determine the media, distribution path, and list of recipients.