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


, , , , , , , , ,

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


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

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


What Users Say Translated to Software Engineering!


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

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.

Software Engineering: How do you start?


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

There are interesting challenges in applying the art and science of Engineering Disciplines to Software Analysis and Design.

If we accept the notion that we need as complete a collection of Requirements as possible either for a full blown application solution (change or new) or a SPRINT to add functionality to either an existing application or to get a new one started, then we also need to decide which models we are going to use to collect these requirements from the Business Users and Sponsors and record them so that the Development and Testing efforts can be coordinated.

The model choices we have are several:

  • Object Models
  • Data Models
  • Process Models
  • Swim Lane Diagrams
  • Use Cases
  • State Transition Diagrams
  • Event Diagrams
  • Data Mapping Diagrams
  • Nassi / Schneiderman Diagrams (don’t remember these?)
  • or simple Flowcharts (a real throwback to a long time ago!)

Which ONE is a good start?  Which combination will the Business Users and the Development and Testing teams understand with sufficient similarity that we can believe we are all talking about the same solution and not something that is not clearly communicated?

One suggestion I would propose is that the “Engineer’s” in the project team do NOT pre-select a model to start with.  Instead, prepare a list of fairly open ended questions for the Business Users and Sponsors and LISTEN to what they have to say about how THEY envision their solution.

You may find that they are very comfortable talking about the information that is available and supportive of their hoped-for solution AND they might also talk about the business events that occur when the data is first available and other events that will change the nature or state of that data as it is used in performing the business.  OR, your users may be more comfortable describing their solution in terms of the Objects or Topics of Interest and the behaviors that they demonstrate as the solution delivers its capabilities.

Once you get the sense of how your users like to describe their vision of the solution, you can pick two or three of the appropriate models to show that you “Get” what they have been saying AND you can also introduce them to the models that seem to represent their vision as close as possible to the ‘syntax’ that they are comfortable with.

The translation of their narratives to you about “Requirements” and the feedback from these diagrams should (underline and bold “should”) facilitate the communication between the Technical and Business contributors assigned to your project.

Let’s CLOUD the Issue..

I just read an article about the word “CLOUD” being more of a verb than a noun so I thought I would add my two cents to this discussion and Cloud the issue some more.

This article was written by someone in a networking group that I have attended in the past and I will, hopefully, get to talk to the author again before too many people get my opinion about whether CLOUD is a verb or a noun.

However, to be clear: I disagree that this word “CLOUD” is more verb than noun and here’s why:

  • If CLOUD is a verb then what observable action takes place when someone ‘clouds something’?
  • If CLOUD is a place where data is stored by owners so that it can be retrieved later to multiple devices then it’s a place and that makes CLOUD a noun.
  • If moving to the CLOUD is a complicated process for an organization regardless of the size of that organization, then the process of moving data to a CLOUD is a verb but the location where that data resides is a place (again) and therefore is a Noun (again).

The other discussions in the article are very valuable and clearly prepared to advise other IT professionals on how to approach the issue of Cloud usage for an organization.  He provides a list of ‘fundamental truths of corporate cloud strategy’ that are worth applying to anyone who is involved in moving an organization into CLOUD usage with very solid reasons to make this change.

However, the premise of this article that CLOUD is a verb is the one point that I cannot agree with.

Because of this opinion I feel obliged to provide a link to this article and so that you can review the author’s credentials and make up your own mind about this; however, considering how far we have yet to go in creating a mature understanding of this CLOUD capability, I think this debate will continue for a long time to come.

The link, then, is:


Thanx for reading!

Structure Programming – Advice from IT.Toolbox

The only point I disagree with in this article is about replicating code for readability!

DO NOT REPLICATE code ’cause it also replicates Maintenance Costs!

Other than that – Bravo to the author: Craig Borysovitch!