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.

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.