The First 90 Days

When I have been asked what I would do in the first 90 days of a new project as the Project Manager, my responses have typically included some or all of the following as a “Self-Orientation Start Up Plan”:

1) Gather the latest project documentation available from the following sources:
a) Portfolio Management files for priority, expected Return On Investment,         relative co-dependence on other proposed and active projects
b) Program Management files for direct dependence on other planned or active projects to determine just how much dependence there is on deliverables and work products from other projects
c) Process Management files for guidelines and standards for how projects are expected to be run for this client / customer
d) Project Management Files to determine if there have ever been similar projects run within this organization and for similar purposes
i) Collect available information on the Project’s / Program’s Scope, Objectives, Goals, Known Requirements and Risks from all perspectives
ii) Collect currently active Project Plans, Issues, Risks, Change Logs and Action Items for active related projects
iii) Collect current and recent Status information on all related projects that are under Execution during or before these first 90 days

2) Review the interrelationships between all available documentation AND
Identify the GAPS in this list where they are not available, not practiced by the client organization, or simply overlooked for this particular effort where others have complied more fully to the incumbent expectations
a) Prepare a list of what is missing, incomplete, or inconsistent in the existing documentation
b) Identify an initial set of Risks, Issues, and needed Action Items that should be acted upon before the final approval for this requested project is given to the Project Team
c) And Determine the recommended work required to complete these items OR get agreement that they will not be needed for this particular project (from the Sponsors, Funding Source, and the Steering Committee, at least)

3) Present and discuss what I consider the current ‘status’ and expected outcomes of the proposed project / program with the entire team of Business Sponsors, Targeted User Management, Steering Committee, Funding Sources, potential Team Participants, possible Third Party Vendors (and their current contracts) as a preliminary Kick Off Meeting

4) Come to an agreement on refreshed materials that satisfy the following Subject Titles:
a) Project Charter
b) Project Scope and Objectives
c) Project Requirements (High Level)
d) Project Budget and Schedule
e) Project Quality Review Schedule
f) Project Dependence on:
i) Third Party Vendors
ii) Other Projects and Programs
iii) Continued agreement on Priority and Delivered Value
g) Project Assigned Resources
h) Project Advisory Personnel
i) Project Steering Committee Members

At times, this information can be gathered in less than 90 days and THAT is a very positive sign of the health and potential success of the project that is being request. The longer it takes to find, understand and correlate these materials, the less likely this project is understood and therefore there will need more Risk Identification and Mitigation efforts to identify things we can learn about that might interfere with the desired successful results.

Orthogonal Views…

A current definition provides us this:

or·thog·o·nal   [awr-thog-uh-nl]

1.  Mathematics .
a. Also, orthographic. pertaining to or involving right angles or perpendiculars: an                 orthogonal projection.
b. (of a system of real functions) defined so that the integral of the product of any                   two different functions is zero.
c. (of a system of complex functions) defined so that the integral of the product of a               function times the complex conjugate of any other function equals zero.
d. (of two vectors) having an inner product equal to zero.
e. (of a linear transformation) defined so that the length of a vector under the                           transformation equals the length of the original vector.
f. (of a square matrix) defined so that its product with its transpose results in the                    identity matrix.
2. Crystallography . referable to a rectangular set of axes.


For Software Engineering, I like to apply this term to describe how two or more  conceptual models in different perspectives will net to Zero when components of an envisioned solution are checked off or aligned with one another.

WHAT does THAT mean?

There are four essential models that can be used to describe a business solution before it is actually specified, tested, or built:

  1. Process
  2. Data
  3. Event
  4. State Transition

When conducting the project phase of Analysis where Business Requirements are intended to be fully fleshed out, these models are used to capture the ideas and expectations that the users, sponsors, management, and technical contributors disclose to the analysts.

By reviewing and comparing each of these models to the others, we can create a list that has each component in each model aligned and “Checked Off” with components in the other models.  For example: A Process and an Event item should be found to describe the same business event from their modeling perspectives.  An Event should be aligned with the appropriate data components to determine that the event can, in fact, begin with a certain condition of the data and end with another.  The evolution in a row of data in a Data Entity should align with a State Transition that reflects and depends on this data transformation.

When each of these models is used appropriately and checked off against the others, every one of modeling components should be referred to and ‘checked off’ (none remaining unchecked)!

Hence, the “Orthogonal” and mathematical proof that a set of conceptual modeling drawings and their associated supportive documentation should net to “Zero” and prove that there is only ONE (and the same) solution being described by each of these models.

Ever Present Project Management Risks

Every project has Risks associated with the delivery of the Business Solution. These need to be discovered as part of the Project Submission process and continue to be anticipated and discovered during the ultimate execution and delivery of the requested business solution.

However, I also believe there are Project Management Risks that are inherent in the process of managing projects from the time they are proposed in a Portfolio or Strategic Planning phase through and including the delivery of the business solution that will be driven by the Project Management efforts.

My favorite list of these Project Management-specific Risks are:

1. Forward progress on an existing plan is at risk unless the team stays focused on the project’s scope and objectives and continues to work on the planned activities

2. Acceptance of Project Deliverables may be delayed by the Project Sponsors if they don’t understand the value, meaning, and importance of its content

3. Available Funding for the project may be recalled when other projects appear to be at a higher priority in the short term

4. Resources working on the project may be re-assigned to other projects if these other projects are deemed to have a higher need because of their timing, poor planning and / or management

Mitigation of these risks can be started as part of the Project Identification / Submission and Portfolio Management activities of each project before each is authorized for funding, resources, and a schedule; however, since these are ‘ever present’ risks, the measurement and risk assessment of these potential hazards must also continue throughout the execution of each project.

A very important early step in Risk Mitigation is Notification to all known participants and stakeholders that we will be identifying these items as Open Risks for the duration of the project. This communication is critical to set the expectations for the Sponsors, Users, Management, Technical and other specialized members of the project team, that we will be treating these items seriously throughout our project’s execution. These ‘ever present’ Risks should be added to the Business related Risks that can also be identified before Execution begins.

In parallel with this Notification of these and other more project-specific Risks, the team should be made aware of the tools and techniques that will be used to measure the impact of these Risks to the overall outcome of our project.

These tools can begin with several of the following approaches and activities:

1. Status Reports written in such a way that each detailed item in the report tells the audience what is expected to happen NEXT (see Risk #1 and #2) once each of the Status Items is included in the report:

a. EG. – The Communication Plan is complete and has been Accepted by the Project Participants and Approved by the Steering Committee.

i. This statement, although correct, leaves the reader thinking that there is nothing else to do now that the Communication Plan is finished. This is, clearly NOT what we want to leave them with.

b. Alternatively – Now that the Communication Plan is complete and Approved, the Project Management Team will begin calling the planned review meetings to measure the effectiveness of the Communication Plan objectives. During these meetings, the Sponsors, Steering Committee, and Participants will have a chance to suggest improvements or changes to the Plan based on our then-current experience.

i. This statement continues to report that the Comm Plan has been Created and Accepted, but it also outlines what must now be done throughout the project since this plan is ready for use / execution.

2. In order to successfully deliver scheduled Project Deliverables (see Risk #3), a Quality Assurance schedule must be established to review these deliverables as they are being developed to assure several things are true:

a. The Deliverable remains “In Scope” and aligned with the Project’s Charter and Goals

b. The Deliverable has not left out or added a new item as compared to earlier deliverables (Project Charter, Scope, Communication Plans, Technical Designs, etc.)

c. The Accepting and Approving audiences for each deliverable are aware of its content, intent, and value before each of these deliverables is ready to be presented to them as “Complete”

3. Regular reporting of the anticipated outcome of the entire project should be provided to the Sponsors, Steering Committee, and Participants so that they are constantly reminded of what they will be getting when the project is successfully completed. This will keep the anticipated value of the project’s results at ‘top of mind’ so that when other projects appear to be in jeopardy (See Risk #4), the decision makers will have the most current information about why our project should remain intact and on plan even if others are not able to maintain their momentum to their projected values.

a. Project scheduling tools and cost tracking capabilities will help to show how much progress has been made on each project against the plan along with predictions of the latest “Estimate To Complete” costs and time so that each project can be compared on, at least, this ROI or CBA level to support any decisions that might be considered for re-prioritizing or re-aligning resources from one project to others.

I assume that many of you have other ‘ever present’ risks attributable to the process and performance of Project Management itself and I would like to hear about them from you.  Please either provide a comment to this blog or send me an email with your thoughts at ‘’.

Thanx, bgbg

Remember Codd and Date?

These were two technology authors who were quoted on the subject of Relational Integrity and a Normalized Data Model.  Their ideas of reducing redundancy in the physical data schema and protecting the mandatory relationships between entities took a whole lot of attention about how to create, define, and manage data so that it was safe and intact for application usage.

They had rules and a syntax for defining data and a normalization process for creating a Data Definition Language (DDL) and Data Manipulation Language (DML) for all data necessary to support the functions of applications.

Use this link for a more detailed discussion on Normalization:

Then, Object Orientation came along and added Methods, Self Contained Data, Anthropomorphism and some other terminology that, although valuable and additive to the definition of solutions, took our eyes off the ball of data modeling principles that are STILL fundamental to a reliable and cohesive solution to business and organizational needs.

Why have we let this happen?

The first computer bug – TODAY’s the day

Check this out about the first actual computer bug ever recorded:


Input – Process – Output

What exactly should a computer program do?  How will you know if the program you have written or requested to be written for you does what you need it to do?

It’s really a whole lot simpler than you might think.

If you, as a business user, can define what information is available to accomplish the automated task at hand (the purpose of the program).  And, you can define, in detail, the processes that are to be done using this available information (the calculations, manipulations, sorting, totaling, etc.).  And define the output results that this program should be expected to provide to you as the user, then you have defined the entirety of your requested program.

A program should only ever take INPUT, PROCESS it according to a business user’s specifications, and create OUTPUT requested by that user.  If a program tries to do anything else other than Process Input to create defined Output, then it is doing more than and probably unexpected things that no one asked the programmer to create.  This would be a BAD outcome.

The Software Engineering science of defining these specifications in these terms has been referred to as a IPO Diagram with three columns.  Can you guess what these columns might be?

IPO Table Sample v1 bg 20110812

IPO Table Sample v1 bg 20110812

If you try this at an appropriate level of detail, you should be able to get a clear understanding of how this can work for you in your business need; HOWEVER, remember that the amount of details you put into this effort will be reflected in the completeness and accuracy of the results.

Syntax of an ERD – Entity Relationship Diagram

Syntax Rules for an Entity Relationship Diagram:

  • An Entity appears as a Rectangular shape with a Name that is represented in the Singular for the subject of the data contained in this Entity.
  • A Relationship Line can be created between any two or more (or’s and and’s) Entities.
  • A Relationship MUST be valid and readable in both directions:
    a) An instance of {the first entity} MAY or MUST have {minimum to maximum} occurrences of {the other entity}.
    b) An instance of {the other entity} MAY or MUST have {minimum to maximum} occurrences of {the first entity}.
  • When the Relationship is Not Mandatory, the MAY will be used and the minimum will be ZERO.
  • When the Relationship is Mandatory, the MUST will be used and the minimum will be ONE.
  • When the Relationship is Singular, the maximum will be ONE; otherwise, the Maximum will be MANY.
  • The Cardinality {minimum to maximum} of these Relationships are sometimes shown as these diagrams as numbers (0,1), (0, many), or a set of predetermined symbols.

An Entity Relationship Diagram Sample:

Use this link: (may have to paste into a browser)

Business Rules derived from this sample are:

  • A Customer MAY have Zero to Many Orders.
  • An Order MUST have One and Only One Customer.
  • An Order MUST have One or More Line Items.
  • An Order Line Item MUST have One and Only One Order.
  • A Product MAY have Zero to Many Order Line Items.
  • An Order Line Item MUST have One and Only One Product.

It is also interesting to note that since there is no relationship between Customer and Product there are no Business Rules that can be derived between these two collections of data (entities).

Process Modeling

Flowcharts, Data Flow Diagrams, Swim Lane diagrams, Use Cases and other constructs have been used to reflect what a Business or Systems Analyst thinks the client is describing when they talk about Business Process and the use of information in the conduct of their business.

These diagrams have structure, syntax, and rules that have been described through the work of authors, vendors, and users throughout their popular years and are still being applied today; however my concern is that these techniques and their principles are being lost in the more pervasive information about AGILE, Iterative, and other quick fixes to some pretty old problems.

Other related types of drawings or ordered lists that I have seen used are: NASSI-SCHNEIDERMANN Diagrams, Functional Decomposition outlines, Warnier-Orr diagramming, Jackson Data Diagrams.  Although these had value in their day, they were not as pervasive as some of the others process and program design diagrams that were mentioned in the first paragraph here.

So, What’s the POINT?  I think that software needs to be an engineered product and these techniques and structured diagramming tools are, to me, a lot like Blue Prints for construction of buildings with electrical, plumbing, HVAC, Safety and Security viewpoints, each of which have similarities in the construction of Software.  And yet, the more recent Software design techniques are focused on RAPID, Iterative, AGILE development that implies to me that current solution development efforts want to skip over those planning, analysis, and design activities while they still expect usable results.

For one, I don’t think this is a healthy evolution for our automated business solutions future.

If you are interested in seeing sample diagrams or starting a thread of conversation about these topics, please send me an email at – thanx, bgbg

Modeling for Money!

One of the basic principles of Software Engineering is the creation of visual models to demonstrate the project team’s understanding of the discoveries we are collecting from the users who are driving our discussions.

The type of drawings were proscribed by several authors of the time but regardless of the style of the drawing, they all have a relatively consistent set of focal points:

  1. Process Definition where a step by step sequence of events was pictured with indications of the data or other resources being used for each process step.  The fundamental assumption was that each process step DID something to input to create its output.  For example: Calculate total line item cost, Apply local and country tax amounts, Add line item cost and taxes for line item total.
  2. Data Definition where a data subject or entity would describe all the details of each data element that was essential for that entry or entity to be “Complete”.  An entity would represent data that was necessary for the functional and operational aspects of the solution without unnecessary redundancy.  Examples are: Product Catalog, Customer Info, Order Details.
  3. State Transition diagrams are used to reflect what “State” each data entity is in when a process step starts and completes.  These “State Conditions” are very useful for managing the evolution of each data entity and preventing some illogical transitions from occurring.  Some examples: New Entry, Priced, Counted, Shipped.
  4. Event Diagrams are supplemental to the Process Diagrams and can initiate process steps depending on occurrences that happen outside of the planned application.  Examples: Customer Submits Order from Web Site, Customer Credit Card fails Authentication.

The Software Engineering Handbook

Information Technology (IT) has been moving towards a “Popcorn Culture” for many years where our Practitioners are regularly looking for a quick POP of a little progress in technology.  When I was growing up in the world of computer programming, we were taught that this work took planning, design, testing, and re-work before a product was “ready for prime time” and then be useful as a Production Program that is reliable, sustainable, and accurate.

I don’t expect that everyone in IT will read my stuff here and turn their lives around to re-acquaint themselves with the principles and techniques of Software Engineering (as I knew it) for designing business solutions; however, I am interested in recording what I believe are fundamentally sound practices for determining what to build and that have value to functioning organizations in today’s and tomorrow’s worlds.

Please let me know what you think about these writings and, if you think they are valuable, please subscribe to this feed, and leave me some comments, so you can get my latest opinions as they are published.

Thank you, Bill Gutches

PS: If you are interested in getting more info on this and other related topics, please send me an email to and I will gladly respond.

%d bloggers like this: