The ability to run things as a project is becoming an increasingly important skill, even for people who do not specialize in project management. This seminar series is also useful for people who use the plans created by a project manager, and who want to make sure their contributions meet the project expectations. We explain the principles of project planning, the use of scheduling software, and a methodology and a consistent work breakdown structure. These same skills can be applied to I.T. projects as well as a broad range of other types of projects that business organizations undertake from time to time, even though the special skills required for dealing with issues and exceptions tend to be different depending on the industry or application context.
We use an I.T. context for most of our examples and we have found that most people can relate fairly well to this context. Clearly the issues will be different for a construction project, a marketing project, a consumer product development project, and so on, but the principles of how to plan and track progress are very similar. This set of topics provides a good basic knowledge of what is involved to organize and manage a project of any kind.

    Introduction to I.T. Project Management
    Project Management Automation
    Systems Development Life Cycle (SDLC)
    Project Planning & Estimating
    Project Progress Tracking
    Project Time and Cost Management
    Work Management Tracking
    Automated Project Estimating

Project Management Office

The ability to coordinate the needs of many projects concurrently is what makes the difference between an efficient IT organization and one that sees costs spiraling out of control. Learn the difference between tracking dates (although important) and optimizing the IT potential to maximize the benefits to your organization: you never look at project management the same way again. In this set of seminars we look at executive level project management in terms of managing the priority of multiple work programs and individual projects that benefit the organization. We also explore the need to maintain control over the focus of approved initiatives, to make sure the corporate interests are protected, and to be able to respond to new opportunities without compromising work in progress.
The most important concept is that there is a hierarchy of control and coordination that must counteract the competitive nature of project implementation. Each project is by nature a specifically focused effort that does not concern itself with other projects unless there is an explicit overriding plan of how projects can use scarce resources or how a large scope can be implemented in stages that are more manageable. This can run counter to the goals and objectives of individual departments or divisions that wish to pursue their own projects even if there are resource conflicts that can affect other departments. The goal of the Project Management Office is to coordinate these individual aims in order to maximize the effectiveness of the organization's resources.

    Introduction to Project Management Office
    Program Management
    Project Portfolio Management
    Strategic Resource Management
    Work Management Portfolio
    Change Management System
    Strategic Initiatives
    Proposal Management & New Business take-on

Project Management Practice

Learn the skills that any Project Management Professional must master in order to implement a successful IT project as covered in this series of seminars. Our focus is to go beyond the PMBOK produced by PMI to show the fundamentals behind the different areas of competency rather than to focus on the PMP exam itself. This is an extensive series of courses that show the depth of knowledge implied by the high-level PMBOK summary. Despite its focus on PMBOK this is not intended to be used as a PMP exam preparation course.
To be consistent with the broader focus of the Project Management Institute this series of sessions is not just IT oriented as it covers a broad spectrum of applications of project management techniques. These techniques were developed in large construction projects, such as the US Navy Polaris Submarine Development project. PMI considers this general knowledge for all Project Managers. We do not believe that a person with good project management skills can automatically transfer their knowledge to switch from implementing a large CRM software project to taking on the overhaul of a Nuclear Generating Station, because the issues that a Project Manager deals with are very different. However, the mechanics behind the management of projects of all kinds are similar and reflected in the Project Management Body of Knowledge that is produced by PMI and that we used to develop the following sessions:

    Introduction to PMBOK Project Management
    Project Management Institute
    Project Management Processes
    Project Integration Management
    Project Scope Management
    Project Time Management
    Project Cost Management
    Project Quality Management
    Project Human Resources Management
    Project Communications Management
    Project Risk Management
    Project Procurement Management
    Project Manager Professional Responsibility

Project Team Management

The skills that a Project Management Professional must master in order to manage the people that make up a project team go well beyond planning and executing a project. Good team skills make it possible for the total productivity of the team to exceed the sum of the individual contributions towards quality final deliverables. This is also a high level overview of Project Management for many participants on a project team that can benefit from a better understanding of the collaborative process required for IT projects to succeed. A project participant must be aware of the direct influence they have on the outcome of a project. It is not unusual for projects to succeed in spite of the quality of management over the team members.
In many cases running projects is only one aspect of a Manager's responsibilities, as it is important to look after the motivation and skills of those assigned to the project. It is easy to overlook these responsibilities if you focus only on delivering a project, and it is too common for Project Managers to complete a project with a burned-out project team that is not mentally capable of considering the next project. This longer-term consequence of how projects can be mismanaged can be avoided if the following techniques are kept in mind:

    Introduction to Project Teams
    Skills Inventory Management
    Multiple Small Projects
    Managing Conflicting Priorities
    The Benefit Of Training
    The Colours of Communication
    Performance Appraisals
    Dealing with Poor Performance

Project Procurement Management

These sessions explain the steps required to purchase software rather than to develop the software internally. This includes commercial off-the-shelf (COTS) software as well as outsourced development. In each case the challenges can be significant to make sure the right product is selected for the right reasons. Our methodology is based on a proprietary Value Analysis approach that is embedded in a procurement model. It is aimed at making procurement options easier to score in relative terms so that there is always an objective selection of the best overall product or service to be purchased. It is possible to be precise and to pursue the selection based on a large number of inputs, without overloading your capacity to manage the final selection of a winning product or service.
We have come across many Project Managers that see a COTS solutions as an easy short-cut to delivering functionality to end-users. In fact, the opposite is true, because failing to deliver the perfect solution with in-house development leaves the door open to revisit the code and to improve the system in successive released. When you purchase software you have to be very specific about what you purchase and it is critical to validate the delivered software to make sure that it meets your requirements before you complete the purchase. If later on you discover that the product does not quite live up to expectations it may be difficult to revisit the purchase and to get the vendor to upgrade the product to meet your true needs.

    Introduction to COTS
    Custom Development
    Cost/Benefit Analysis
    Software Procurement - Prepare RFP/RFQ
    Software Procurement - Evaluate Proposals
    Managing the Procurement Process
    Procurement Contract
    Selling a COTS solution

We must understand the role of QA in preventive participation in projects to facilitate the production of quality final deliverables. Prevention yields low-cost problem solutions that are much easier to implement before errors are allowed to propagate throughout the development deliverables. In our seminars we stress that every opportunity must be pursued to catch bugs as early in the process as possible, to minimize the cost of development. Not only are we concerned about a single software product, we need strategies to cope with the combination of products that must coexist in different computers. We need to keep track of changes that may affect already installed software, or that may make existing products obsolete. That means it is necessary to consider the QA role well beyond the scope of software development (or procurement), and it means that IT QA practitioners must be well trained and versatile.
The list of topics below indicates that we take QA serious, it goes well beyond the testing effort that is the focus of QA in most projects. It is the basic question of how do we know we have a system that does everything that is expected of it, and nothing more. This questions is not easy to answer, certainly not if you consider COTS solutions or offshore development efforts. We see QA as involved in all aspects of the development life cycle, as illustrated below, even if you outsource some aspects of QA as part of the development effort.

    Preventive Quality Assurance Analysis
    Requirements Assessment
    Reconciling Specifications
    Unit Testing Strategy
    Unit Testing Framework
    Integration Testing Strategy
    Integration Testing Framework
    Application Test Plan
    Failure end Effects Analysis
    Scenarios and Test Cases
    Application Test Scripts
    System Testing Introduction
    System Testing Strategy
    Systems Test Environment
    Test Data Requirements
    Business Testing Introduction
    Business Acceptance Test Plan
    Production Testing Introduction
    Pilot Testing Introduction

Quality Assurance Execution

You must understand the role of QA in corrective participation in projects to facilitate the production of reliable software by finding the bugs hidden in the code. We explore detection techniques used to identify weaknesses that should be addressed, while priority-based correction effort can be used to minimize the cost impact of emergency fixes that may be deferred to be included in a later release of the product. Problem tracking and change controls are critical components of managing the costs of quality assurance execution. In this series of seminars we focus on tools and techniques that you can use to bring the testing challenge down to size. In our approach we explore both manual testing and the tools available to automate the testing, and we explain why both approaches should coexist. With a little planning the job of testing complex applications can be fun so long as you are focused on a common objective of customer satisfaction.
A major focus for us is to find ways to reduce the cost of QA execution by introducing automation to supplement the efforts of manual testers. While we suspect that there will always be a need for manual testing, if only to verify problems identified by automated test results, or to evaluate the usability of product user interfaces, much repetitive testing work can be done using automated tools. For practical reasons this testing is focused on System Test Execution that evaluates the detailed functionality of an application. Elements of this testing can then also be used for Business Testing, but any fundamental usability testing has to be done manually to fully appreciate how the system interacts.

    Introduction to Test Execution
    System Testing Preparation
    Test Data Generation
    Change Management
    Problem Management
    Test Scheduling
    Manual Testing
    Qualities of a Tester
    Automated Testing - Introduction
    Automated Testing - Capture/Replay
    Automated Testing - Detailed Scripts
    Automated Testing - Automated Scripts
    Automated Testing - Scheduled Scripts

Quality Assurance Governance

Understand the System Development Life Cycle methodology to make sure that all projects follow the proven steps that most likely result in producing quality deliverables. Governance is the control process that is needed to get people to adhere to the chosen methodology. Its responsibility is both proactive, to explain the benefits of the SDLC methodology, and corrective, to review and approve the work performed as substantially in accordance with the methodology. Governance is also about keeping a process in check, without stopping the natural progression of process improvements. Methodology is based on learning from past practices and it is intended to use best practices to be repeated and honed, not to stifle growth. A central element of QA Governance is to provide guidance with respect to interpreting the SDLC methodology in projects that deal with radically different applications so that the code can be maintained by the same technical support staff.

    Introduction to QA Governance
    System Development Life Cycle (SDLC)
    Project Management Life Cycle (PMLC)
    Enforcement vs. Education

Quality Assurance with Six Sigma

Understand the larger picture of quality that has evolved into a total quality culture. There are several contributing measures of quality that you can use to assess your QA effectiveness beyond developing or buying the best IT applications you can afford. A quality culture has to be established in all areas of an organization to open peoples' eyes to where or how opportunities for improvement can be identified. IT should be one of the tools for enabling quality initiatives with a profound impact on your organization. The challenge of Six Sigma is to achieve zero defects in order to minimize the cost of software development. It is but the latest of a series of quality improvement initiatives, some of which will be explored in this set of seminars. What these techniques have in common is the indoctrination of staff to focus on total quality, and to look for opportunities for improvement in all aspects of the work that is performed in different departments. This series explains internal process improvements as well as improved customer focus objectives.

    Introduction to Six Sigma
    Application of Six Sigma
    Techniques used with Six Sigma
    CMM Capability Maturity Model
    Introduction to ISO 900x Certification
    Introduction to Total Quality Management
    Application of Total Quality Management
    Implementation of Total Quality Management

As seen with the '9/11' disaster, companies can be wiped out in an instant, while others manage to recover from devastating losses. The great power failure of 2003 signaled an era of uncertain operating continuity may have started. Learn what you can do to increase the chance of your company recovering from any number of potential disaster scenarios, some of which may be easier to predict than others. This course series is based on our proprietary BIRP methodology for addressing Corporate BCP instead of focusing on Information Technology. BIRP stands for Business Interruption Response Planning, which is much more to the point with respect to what is important in a crisis. You never know if some bulldozer operator mistakenly knocks over a hydro tower in your industrial park, so you must learn to be the first company back in operation when the power comes back on by having the right response plans in place.
We try to make BCP easier to implement, illustrated by our 6-step program RECIPE outlined in the session titles below. The idea is not to get cute, but to bring the effort down to earth in an attempt to make your job easier. If everybody can understand the BCP goals and objectives there is more likelihood that you will be able to put the program into effect and that people will be prepared to take the necessary steps to respond to any emergencies. This goes well beyond taking offsite copies of critical files. We stress the opportunities to prevent serious damage and injuries, let alone loss of life, that should be the focus of any BCP effort.

    Introduction to BCP
    Risk Identification
    Exposure Assessment
    Consequences
    Impact Analysis
    Prevention
    Executing a BCP Plan - Dry Run
    Executing a BCP Plan - Emergencies
    Draft & Maintain the BCP Plan

Understanding the business requirements is the most critical aspect of any project, to make sure that the development or procurement effort addresses the critical needs of the business organization. Remarkably, many initiatives are started without a detailed assessment of what the true business needs are, and this has a greater impact on the effectiveness of IT projects than any other steps, simply because everything is dependent on this understanding. Some authors have argued in jest for scrapping the requirements definition because of their general inadequacy, but few have actually offered reasonable alternatives that would remedy the situation.
In this series of seminars we look at the foundation of business requirements in the context of using I.T. systems as the enabling technology that changes the way a company works. This is a significant observation of the reasons for developing some systems, and for buying COTS (Commercial Off The Shelf) solutions for many other systems. Regardless of what systems you implement they will affect the strategic direction of the company and, if you do not understand the dynamics, you can inadvertently cause a company to pursue the goals that are inherent in the software paradigm but that may not be consistent with actual planned corporate direction.

    Introduction to Business Requirements
    Long-term Strategic Planning
    Program Management Concepts

Business Requirements Analysis

Knowing what you want done for a business must be evaluated in terms of how to implement solutions so that all areas of the business are well served by a new application. We use a proven, down-to-earth methodology for the evaluation of business requirements to elicit the departmental use-case needs. We do not use the graphical representation popularized in recent tools because we are concerned that this may compromise the analysis by putting too much of the effort on the presentation of what is being identified. Besides, we want to focus on general principles rather than on specific proprietary approaches. The skills covered in this series of seminars are the most critical to the success of a future development project, yet in many ways they are poorly understood and, as a result, often ignored as critical stepping stones towards a successful project.
Business requirements are fundamental to development and procurement alike, because they define what the software services must provide, not how they should provide the results. It does not matter much how well that software works if it fails to meet the services defined as essential to the business. Software must support the business operations, and the only context in which you can accept that software sets a new direction is if you want the software to become the enabling technology of that new direction. This can be purchased software, as in the case of a commercial credit scoring application or fraud detection application that adds net new capability to your company. However, you would not want to change your accounting practices if you happen to switch over to a new accounting software package, but you would insist instead that the existing practices be supported by the new software. That is why it is essential that you perform a detailed business requirements analysis.

    Business Requirements Analysis
    User Requirements Analysis
    Functional Requirements Analysis
    Non-functional Requirements
    Feasibility Study
    Usability Modeling Concepts
    Operation Simulation Concepts

Functional Specifications

Whether you make or buy, you need to define in detail what exact functionality must be implemented across all requirements in order to get the correct implementation for your company. Unless requirements are written down in an unmistakable format you will always run the risk that people interpret your needs differently from what you expected. Requirements are the key to successful development and to subsequent testing of that development effort, and as well for the procurement of adequate software that must meet the needs of your organization. Without requirements the developer or vendor has no idea what it is that you are looking for and there will be little chance that your new system will provide the services you really wanted.
In the following sessions we will explain the differences between basic requirements that outline WHAT you want from a new application to detailed specifications that outline HOW you want that application to work. There are many reasons to be specific, in particular if you want the new system to coexist with existing applications. It is not difficult to develop stand-alone applications, but it can be tricky to develop applications that seamlessly blend in with your existing operations. Some vendors know that they can deliver code that functionally meets your needs and at a competitive price, because once you want to integrate that code with the rest of your systems the costs can escalate rapidly. Once you consider what is involved in making your new software compatible with the rest of your operational inventory you will understand why.

    Functional Specifications
    Governing Business Rules
    Detailed Design Specifications
    Data Model Specifications