IT Project Management Software & Efficiency Solutions

August 2010 - Posts

• The "V" Model -by Cameron Watson

  Context From its inception Information Technology (IT) has recognized the significance and importance of developing and applying a set of "standards", "methodologies", "lifecycles" and "best practices" that can be leveraged by all practitioners.  As the industry has evolved, the technologies have become more complex, increasingly faster, and forever changing, however, there remains a set of basic principles and concepts that are as applicable today as when IT was in its infancy. One of initial concepts created and applied by early IT practitioners was the "V" Model. It was created to ensure project teams had a mechanism with which they could accurately define and refine user requirements design and build an application according to the authorized user requirements validate that the application they had built adhered to the authorized business requirements The "V" model evolved in the 1960's - since that time various institutions and authors have revised, enhanced and extrapolated on it. It is possible to see a multitude of versions of the "V" model - each with its own customized terminology, phase names, and depictions. Though the IT industry has made significant strides since its inception, the principles defined by the "V" model are as applicable today as when the model was first created.  "V" Model Diagram - Construct For the sake of this document we have used the above diagram as a basis to illustrate the "V" Model. It consists of shapes, arrows, and terminology - this structure will be used to explain the underlying principles of the "V" model. Circles - At the upper left and upper right corner of the diagram are two green circles - they are used to denote the origin and completion of a project. The "V" model does not address the factors or activities an organization utilizes to authorize the startup of a "project" nor does it address the procedures or organizational infrastructure required to support an application once it is developed and made available in a production environment.   Rectangles - Seven rectangles are identified on the diagram. The generic terms (Requirements Definition, High Level Design, Detail Design, Coding, Unit Testing, Integration Testing, Acceptance Testing) have been used to reflect the phase names that are applied by a number of industry recognized methodologies.  The "V" model does not suggest, imply or demand the terms an organization uses to define its development process, phases or methodology  (i.e, an organization using the term "Preliminary Analysis" as its initial phase to define requirements would use that term rather than "Requirements Definition" depicted in the illustrated  "V" model). Diagonal Arrows - Two diagonal arrows are used to distinguish the flow of a project. One arrow originates at the top left (Project Startup) and flows through to the coding phase of the project - this arrow reflects the development portion of the model. The other arrow originates at coding phase of the project and flows through to the project being delivered to the maintenance and support team - this arrow reflects the testing portion of the model. Horizontal Arrows - Three horizontal arrows are used to illustrate that there must be a correlation between the development portion (requirements definition and design) of the model and the testing portion that has to be performed to verify that the application being built reflects the authorized requirements and design.  These horizontal lines have been labeled with "Review/Test". "V" Model  - Principles The following principles are inherent when the "V" model is applied. Large to Small - This principle states requirements, standards, testing from a hierarchical perspective. For example, requirements (left side of the diagram) are identified and defined as a project team evolves through the Requirements Definition, High-Level Design, and Detailed Design phases of their project. As each of these phases are completed the requirements they are defining become more and more refined and detailed (when defining the requirements to build a space shuttle a requirement defined during the Requirements Analysis phase may be that the space shuttle required landing gear whereas a requirement defined at the Detailed Design phase would be that the wheels of the landing gear are to be made of rubber and able to withstand the force of landing at 300 mph - the requirements get further refined with additional granularity as the project evolves). Data/Process Integrity - This principle states that the successful design of any solution requires the incorporation and cohesion of both data and process(es). As the requirements are defined data and process elements must be identified for each and every requirement. Scalability - This principle states that the "V" concept has the flexibility to accommodate any IT project irrespective of its size, complexity or duration. The "V" concept is as applicable to a large mainframe development project applying a waterfall approach as it is to a web-based development project applying agile techniques. Cross Referencing - This principle states that there must be a direct correlation between every requirement that has been defined with a corresponding and verifiable testing activity and result that substantiates that each and every authorized requirement has been incorporated into the completed application. Tangible Documentation - This principle states that there must be tangible documentation (electronic and/or hardcopy) created as the project evolves. This documentation is required and applied by both the development project team and the support team that will be maintaining the application once it is available in a production environment. The "V" model does not suggest specific document titles or templates or formats. The "V" model does not suggest how many documents must be prepared or authorized or utilized throughout the projects life. "V" Model Flow - Seven Steps Step I - At this level (Requirements Definition and Acceptance Testing) the project team is accountable for three primary responsibilities. The first responsibility is to begin defining the high level (most broad) requirements of the application being developed. The second responsibility is to begin planning the testing activities that will have to be performed to verify the high level requirements have been incorporated and satisfied. The third responsibility is to establish the pre-defined conditions that will have to be tested to verify the high level requirements (most broad) have been incorporated and satisfied.  Step II - At this level (High Level Design and Integration Testing) the project team is accountable for four primary responsibilities. The first responsibility is to further refine the granularity of the high-level requirements established during the Requirements Definition phase. The second responsibility is to begin creating a high level solution design based on the requirements established during the Requirements Definition. The third responsibility is to begin planning the testing activities to be performed to verify the requirements (at the High-Level Design phase) have been incorporated and satisfied. The fourth responsibility is to establish the pre-defined conditions that will have to be tested to verify the High-Level Design phase requirements have been incorporated and satisfied. Step III - At this level (Detailed Design and Unit Testing) the project team is accountable for four primary responsibilities. The first responsibility is to further refine the granularity of the requirements established during the High-Level Design phase. The second responsibility is to continue refining the design and solution based on the requirements established during the High-Level Design phase - this includes the creation of specifications (functional and/or technical) used to create the application. The third responsibility is to begin planning the testing activities to be performed to verify the requirements (at the Detailed Design phase) have been incorporated and satisfied. The fourth responsibility is to establish the pre-defined conditions that will have to be tested to verify the Detailed Design phase requirements have been incorporated and satisfied. Step IV - At this level (Coding) the project team has one primary responsibility.  That responsibility is to translate the specifications created in the Detailed Design phase into technical code (in whatever platform or language). Step V - At this level (Unit Testing) the project team is accountable for three primary responsibilities. First, to execute the Unit Test phase activities according to pre-defined Unit Test plan (established in Step III). Second, to identify and document deviations between "pre-defined anticipated results" with "actual testing results" for each and every unit/program.  Third, to ensure all pre-defined Unit Test cases have been executed and all the expectant results have been achieved. There will be one or several iterations of this step between the development team and the testing team to ensure all of the appropriate requirements have been defined and successfully tested - once this step has been finalized the project team will continue with Step VI. Step VI - At this level (Integration Testing) the project team is accountable for three primary responsibilities. First, to execute the Integration Test phase testing activities according to plan (established in Step II). Second, to identify and document deviations between "pre-defined anticipated results" with "actual testing results" for each and every sub-system.  Third, to ensure all pre-defined Integration Test cases have been executed and all the expectant results have been achieved.  There may be one or several iterations of this step between the development team and the testing team to ensure all of the appropriate requirements have been defined and successfully tested - once this step has been finalized the project team will continue with Step VII. Step VII - At this level (Acceptance Testing) the project team is accountable for three primary responsibilities. First, to execute the Acceptance Test phase testing activities according to plan (established in Step I). Second, to identify and document deviations between "pre-defined anticipated results" with "actual testing results" for the application.  Third, to ensure all pre-defined Integration Test cases have been executed and all the expectant results have been achieved. There may be one or several iterations of this step between the development team and the testing team to ensure all of the appropriate requirements have been defined and successfully tested - once this step has been finalized the project team will have completed its work and the application can  be made available in the production environment. "V" Model Diagram - Benefits Applicability - the "V" model affords organizations and project teams a guide to performing and completing projects in a consistent and repeatable manner. Applying the principles of the "V" model ensures the user requirements are identified and documented, the authorized requirements can be traced into the functions of the completed application, and the application reflects the user requirements. Flexibility - the principles of the "V" model are applicable in both development and maintenance/support environments and can be applied using one or many (spiral, rapid application development, prototyping, waterfall, agile) approaches. Formality/Process - in applying the principles of the "V" model an organization can establish a formal and standardized process they use to develop and/or maintain applications. Having a standardized process enables them to quantify the quality being delivered by the process, establish and leverage process metrics to continually evaluate and improve the process, increase versatility of staff to work on varied applications, reduce training costs by limiting the number of lifecycles, methodologies, deliverables being used by multiple application teams. Support Documentation - there is always a balance that must be considered when developing a new application. The equation - the time saved to create the application by accelerating the development process versus the time lost in trying to find information to maintain the same application without effective reference material and documentation. Every organization is unique as are the environments, methods, tools, and techniques they use to develop and maintain applications - the amount of documentation needed is subjective to the organization. The "V" model provides a logical and practical framework to ensure the appropriate amount of documentation can be created during development and referenced in support. Adherence - all of the principles of the "V" model can be applied using the majority of all industry recognized methodologies, lifecycles and project management tools. Cameron Watson Cameron Watson is the President of QAIassist. QAIassist helps organizations increase and optimze their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Posted Aug 26 2010, 01:22 PM by angelacastro with no comments Filed under: methodology, IT, implementation

• Meet Your New Best Friend: the "Project Charter" -by Cameron Watson

  The project charter has been around for as long as the concept of work. The Egyptians used project charters to create the Pyramids. So did the Greeks to erect the Parthenon. Even the Romans used a project charter to create the Coliseum. Little Johnny used a project charter to construct his miniature house made of Lego blocks. As different as the times and methods used to create these structures, one common thread exists - success was based on the creation, maintenance and oversight of a project charter. The Egyptians may have created theirs with hieroglyphics in the sand, the Greeks may have chiseled theirs in Mount Olympus, the Romans may have penned theirs in Latin and little Johnny may have used Crayola on the kitchen table. The point is not how complex or sophisticated these project charters were, but rather, that one was required, prepared and relied upon to act as the cornerstone to creating all of these structures. While academia can spend days crafting a definition of the complexities and internal dynamics of a project charter, anyone can understand it using six simple words: "what are we trying to do?" Though the term project charter is routinely applied and recognized within the Information Technology (IT) industry, the concept of project charter is as applicable to organizational strategic planning, corporate budgeting and operational oversight. It is difficult to fathom a corporate president or CEO performing their roles without defining and documenting "what are we trying to do?" or a CFO maintaining fiscal control without defining and documenting "what are we trying to do?". The question of "what are we trying to do?" permeates every facet of every organization. Suffice it to say, the tenure of a CEO would not be very long if they were unable to articulate and gain approval of "what are we trying to do?" from the shareholders. On the surface, addressing the project charter "what are we trying to do?" question appears to be a simple exercise, be it a CEO, CFO or an IT Project Manager. In reality, it can become a very trying and taxing exercise. The amount of definition and explanation required in a project charter depends upon the magnitude and complexity of the "what are we trying to do?" question. A project charter used to document how one person should dig a hole in the ground could be documented on half a sheet of paper, while a project charter used to document how to send a space craft to the moon and back would probably require volumes of detail.  The utilization of a project charter is as varied as the number of organizations that create and apply them. In some cases the project charter is the project's bible and is relied upon throughout the project. In others cases, the project charter is a project title and a brief project description. The project charter has been adapted and customized by organizations to address a myriad of needs. Here are a few contexts where the project charter is used. Corporate - Project Definition  As an initial project document, the project charter establishes the goal posts from which the project will be initiated, planned, pursued and completed.  The project's definition will reflect its size and complexity. It can include the following: The purpose of the project The scope The objectives The resources (HR and otherwise) to be utilized on the project The plan The constraints The quality The cost estimate Project hierarchy and organization Risks and impacts the project will have on the organization. The project charter is not a stagnant document; it evolves and is maintained to reflect the changing circumstances and conditions associated with the project. The project charter acts to establish the project context and boundaries to ensure all project team stakeholders and resources have a common point of reference and communication of the project throughout its duration. Corporate - Project Authorization The project charter gives organizational stakeholders the ability to review and evaluate priorities. Utilizing the project charter to obtain formal authorization ensures there is a correlation between the corporate strategy, planning and budgeting exercises and the organizational resources allocated to complete a project. This ensures organizational resources will remained focused on the authorized projects. Corporate - Project Scope Management After establishing the project context and boundaries, and receiving formal authorization, the project charter can be used to monitor and evaluate the scope of the project from beginning to end. Project stakeholders are able to reference the project charter to monitor the project progress and direction in relation to the original context and boundaries they had originally approved. This affords project stakeholders the flexibility to stop, defer or accelerate IT project team priorities to better reflect organizational business needs. It also enables IT project team resources the ability to re-calibrate their efforts based on decisions and approvals of organizational stakeholders.  Corporate - Formal Deliverable The project charter establishes an operational premise to promote structure and formal documentation. This is very important to the efficiency of IT delivery and support. This concept of structure and documentation can be leveraged by the organization to introduce quality assurance and to improve the maintenance and support of applications. Project - Planning & Oversight Benchmark Once authorized, the project charter can act as the basis for a project planning exercise. The Project Manager is able to reference the original definitions established and authorized in the project charter to provide greater clarity and detail on how the project will be executed. Project plans, project schedules, project resources and project budget allocations are derived from the authorized project charter. Project - Team Communication The authorized project charter provides the mechanism the project team will rely on throughout the life of the project. It acts as the basis for the deliverables and work products identified in the project plan and project schedule. Having formal documentation prepared provides several benefits. Project development teams will have access to the necessary information to ensure project team communication is consistent and based on formal approvals - all project development team members can rely on the authorized deliverables to ensure they are working off the same page. Application support and maintenance teams have a common point of reference they can leverage to effectively maintain and incorporate new functionality into the applications. Wrap Up  Although the concept and need to create a project charter has meant different things in different environments for different audiences, its primary purpose has remained the same. Be it the Egyptians or Little Johnny, as long as the concept of work exists, success will be dependent on our ability to understand the question of "what are we trying to do?".  A project charter helps us to answer that question.   Cameron Watson, President, QAIAssist     Senior manager with over 20 years experience in optimizing business operations in the private and public sectors including financial services, banking, consulting and aerospace industries. Watson has a proven track record in leading large and medium sized organizations through successful implementation of organizational "best practices", process management and improvement, re-engineering, and "quality" initiatives. QAIassist helps organizations increase and optimise their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website-www.qaiassist.com Posted Aug 26 2010, 01:17 PM by angelacastro with no comments