K P I Requirements

Tags

analysis, design, infrastructure, management, modeling, perspective, planning, process, project, recovery, requirements, resources, software, technology

Key Performance Indicators are measurements and projections that can help a management team make decisions about the Strategic and Tactical Plans for the future of an organization.

Many business requirements describe operational necessities of an application or a business App or Function but how should we expect a Requirement for a K P I automated function be stated?

In the following list, I would like to prompt / instigate some higher order thinking about Requirements that we can document to be included in our new application development efforts so that the app can support or anticipate how the active executive or decision making management of an organization can use the operational data to consider new decisions:

• What is a predictive inventory forecasting tool?
  • What could it be used for?
• What could dynamic Purchase Order generation do for our organization?
  • What would we base the automated PO Generation on?
• Could we predict the need for additional staff in specialized areas of our product or service delivery organizations?
  • Based on what criteria?
• What information would be useful to re-design manufactured products to increase useful life, reduce maintenance costs, and provide more value to our Customers?
• …

What questions would YOU like to ask of your operational data that could help you make critical business model decisions in the foreseeable future?

Time for THE BOOK

Tags

agile, analysis, best practice, career, conflict, data, design, event, file, flowchart, infrastructure, life, lifecyle, management, modeling, organization, perspective, planning, process, program manager, project, project manager, quality, records, relational, requirements, resources, retention, schedule, scheduling, scope, SDLC, software, state, technology, use case, visual

A few weeks ago (May 2018), I started a “Go Fund Me” site to gather some money so that I can publish “The Book” that represents many of the ideas from this blog.

The Title of the book will be: “IT’s Lost Art of Software Engineering” and will contain much of what has been posted in this blog for the last few years.  If you are interested, please use the link below to review my Go Fund Me site and, possibly, make a donation for me.

https://www.gofundme.com/bg039s-software-engineering-book&rcid=r01-153045704526-710aea5b95e24eeb&pc=em_co_campmgmt_w

Please keep in mind that anyone who donates $10.00 USD or more will get a FREE and SIGNED copy of the book (I will need a mailing address after the donation) once it is available in hard copy.

Your support would mean a lot to me. Thank you so much!  bgbg

27 Aug 2018: The Go Fund Me effort is dragging on very slowly and, if it doesn’t pick up its pace relatively soon, I will probably decide to return the few donations I have received and shut down this effort.

However, there is still time so if you want to make a donation (and get a FREE SIGNED copy of the book) please go to my Fund Me page (https://www.gofundme.com/bg039s-software-engineering-book&rcid=r01-15353992165-7b0de45af8ef42b2&pc=ot_co_campmgmt_w) and make a $10 or more donation quickly.

Thanx you in advance, bgbg

 

With Great Data, comes Great Opportunity

Tags

agile, analysis, best practice, data, data design, design, event, functional decomposition, iterative, modeling, requirements, scope, state, state transition, use case

There once was a line in a movie: “With Great Power Comes Great Responsibility.”

My take on that is that the more Data we receive, the more Opportunity we get to use that data.

Big Data, the Internet of Things, Business Intelligence and the current evolution in newer, faster, fresher data puts responsibility and opportunity squarely in our laps or IDE’s (Interactive Development Environments) if you will.

What, if anything, are we doing to prepare for these opportunities and responsibilities?

I would really like to hear your thoughts on how we prepare.

The Path To Inkc Profile

Tags

best practice, business sponsors, data, data design, flowchart, functional decomposition, iterative, modeling, old school

• How many ways would you be willing to collect income:
  • Full Time Employment with Salary and Benefits?
  • Part Time Employment paid by the Hour or Piece of Work?
  • Signed Master Service Agreement(s) for predefined services, rate and duration?
  • Signed Purchase Order(s) for your product offering(s)?
  • Incorporation of your own new company and the creation of new jobs for yourself and others?
  • Royalty / Investment Income?
• Do you still think that you only need ONE Source of Income to survive in our current world?

I don’t expect that many people could manage all of these incomes sources (or others), but wouldn’t it be nice if you could maintain two or more of these?  And, IF one of your new income sources were to “dry up” for a time, wouldn’t it be nice that you could have the others to keep you going?

If the answers to these questions intrigue you, reach out to me for an initial free review: William (Bill) Gutches at 610.662.5658 or whendoyoustoplooking@gmail.com .

My Social Media Web Presence techniques and Business Planning experiences coupled with your passion for your products and/or services have the potential to get you in a position where two or more of these income sources can be sustained.  Please let me know if you are interested in talking to me about these possibilities.

William (Bill) Gutches ► Social Media ☑ Web and Blog Content ☑ Income Search Coach ☑Business Planning Coach ☑ Contact Info: ☛ whendoyoustoplooking@gmail.com  ☛  610.662.5658

Swim Lane Diagrams

Tags

agile, analysis, best practice, business sponsors, conflict, data design, design, functional decomposition, iterative, lifecyle, management, model choices, modeling, old school, perspective, planning, process, requirements, scope, state, state transition, state transition diagrams, swim lane, use case, visual

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

Starting your own PMO

Tags

agile, analysis, best practice, business sponsors, iterative, lifecyle, model choices, modeling, old school, planning, priority sequence, process, project charter, project priority, punch list, requirements, scope, SDLC, technology

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

Tags

analysis, best practice, business sponsors, lifecyle, process, project charter, recovery assessment, requirements, scope, SDLC

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”:

https://softwareengineeringhandbook.wordpress.com/2012/01/04/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!

Software Engineering: How do you start?

Tags

analysis, best practice, data, data design, event, flowchart, functional decomposition, iterative, model choices, modeling, nassi-schneidermann, process, requirements, scope, state transition, state transition diagrams, swim lane, use case

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.

The First 90 Days

Tags

analysis, best practice, first 90, flowchart, functional decomposition, iterative, lifecyle, old school, planning, portfolio manager, process, program manager, project manager, recover, recovery, scope, SDLC

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…

Tags

analysis, best practice, data, design, event, flowchart, iterative, lifecyle, modeling, process, requirements, scope, state transition, technology, use case, visual

A current definition provides us this:

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

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.