IT Project Management Software & Efficiency Solutions

Context

One of the questions I am asked most frequently is “What is the most important deliverable of an IT methodology”?

The simplest answer is “it depends”. The more appropriate answer is “it depends on the scope of the project, whether a project team has been assembled, whether the project has been approved, if user requirements have been defined, what the technical alternatives are, when the project has to be completed, if the business users have been trained, etc, etc, etc”. 

Every project is different. Every project stakeholder is different. Every project team is different. Every deadline is different. The uniqueness and dynamics of these ever changing variables ensures the “deliverable” deemed “most important” will change as the project and project team evolves. When I am faced with this question I usually try and respond with a story about Snow White and the Seven Dwarfs.

Stew Anyone

Once upon a time Snow White had invited all of the dwarfs over to her place for dinner. The first thing to meet the dwarfs upon their arrival was the aroma emanating from the kitchen – its scent was delightful and they kept asking Snow White what was for dinner. After some coaxing Snow White revealed that she had made up a pot of stew. 

The Dwarfs conceded that they did not know what stew was and wanted Snow White to tell them what the ingredients were. Snow White relented and said “my stew is made up of a number of things – roast beef, potatoes, carrots, yams, peas, barley, and celery.”  Snow White then invited the Dwarfs into the kitchen to look into the pot as the stew simmered. The Dwarfs were so excited to see the stew and each of them kept telling Snow White they could not wait to try it. They all promised they would eat all of their stew.

After viewing/smelling the stew, Snow White told the Dwarfs to find their seats at the dining room table and she would bring the stew out for everyone to enjoy. The Dwarfs gleefully found their spots at the table and were eagerly awaiting Snow White to arrive from the kitchen. Snow White entered the dining room with a huge bowl of stew and told the dwarfs to help themselves to a serving while she went back to the kitchen to get the salad, the buns and to make sure she had turned off the oven.

Upon her return to the dining room, Snow White was pleased to see the hungry dwarfs devouring their dinner and asked if they were enjoying the stew. Their collective response was a resounding “yes!”.  In hearing this praise, Snow White sat down at her place at the table to recognize a most disconcerting reality - Sleepy had only the roast beef on his plate, Dopey had only the potatoes on his plate, Sneezy had only the carrots on his plate, Happy had only the yams on his plate, Grumpy had all only the peas on his plate, Bashful had only the barley on his plate, and Doc had only the celery on his plate. 

Upset, Snow White confronted the Dwarfs saying: “Why did you separate all of the ingredients in the stew?”  Each of the Dwarfs responded with the same answer: “We each knew what we liked and knew we would enjoy our own if we separated the ingredients.”

Snow White got up from the table, went back to the kitchen and returned with another large bowl of stew. This time she served the Dwarfs herself – each receiving a plate full of all the ingredients. After a little encouragement each of the Dwarfs tried the new concoction – with every mouthful the smiles on their faces got broader and broader. The Dwarfs had come to realize that the combination of all the ingredients was the true secret to success.

Moral of the Story

Although an IT methodology is made up of specific and unique deliverables, its true value is best realized when the all deliverables are used together throughout the life of the project. An approved User Acceptance Test Authorization deliverable utilized at the completion of a project is no more or less important than the Project Charter that was created to initiate the same project.

Bon Appetit!

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.

 

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 its practitioners – the underlying objective has always been to increase the efficiencies of IT resources in the field.  As the industry has evolved, the technologies have become more complex, increasingly faster, and forever changing, however, despite all of these advancements the IT industry remains in a self induced dilemma surrounding some of its most basic terminology.

To prove this point all we have to do is identify an unbiased audience of IT practitioners, establish a reliable sample population of that audience, ask the same specific question to each individual of the sample population, and document the responses provided by each individual of the sample population. With this approach in mind I recently attended a conference of several hundred IT professionals and practitioners. Attendees at the conference included senior management, business stakeholders, project managers, business analysts, architects, programmers and testers. My goal was to obtain a true and reliable perspective of what IT professionals understood the term “IT Methodology” to mean.

Applying these parameters I began on my quest. I set a target of speaking to 40 independent IT practitioners with a minimum of 3 years of IT experience – the population of 40 IT practitioners consisted of senior managers, business stakeholders, project managers, business analysts, programmers, testers. The following question was posed to each and every one of them. The question - Is “IT Methodology” a noun or a verb?

Without exception, all of the individuals asked the question were aware of the term “IT Methodology”.

• 50% of those who responded said an “IT Methodology” was a noun – they cited PMI Project Management, IBM’s Rational Unified Method (RUP), Prince2, QAIassist Integrated Methodology as some other methodologies they had used
• 30% of those who responded said that an “IT Methodology” was a verb – they cited their experiences with delivery approaches such as waterfall, agile, RAD, prototyping and spiral
  
• 10% of those who responded said that an “IT Methodology” was both a noun and a verb – they cited both of the above mentioned responses
• 10% of those responded would not commit to stating whether “IT Methodology” was either a noun or a verb – they were not sure either way

Suffice it to say, these collective responses were not what I had anticipated, they left me somewhat puzzled and concerned from a number of perspectives.

After giving these “unofficial survey” results a couple of weeks to resonate (and getting away from the emotion), I have taken it upon myself to try and articulate why the results of my “unofficial survey” were so disturbing to me. I have created the following examples to provide a context for the discussion.

Example I – Flying a Commercial Jet

Two pilots are scheduled to fly a commercial jet full of passengers from New York to London. The pilot is experienced and well trained; the co-pilot is new to the profession and learning on the job.  During take- off the pilot guides the plane down the runway and safely elevates it into the sky. During the flight the pilot decides to catch 40 winks and hands control over to the co-pilot – he then drifts off into gentle slumber. Forty minutes later the pilot is awaken by the jolt of his seatbelt harness locking him into his seat – it doesn’t take him long to realize the co-pilot has lost control of the plane. Instinctively the pilot grabs the stick to resume control and take the plane out of its spin – he starts issuing directions to the co-pilot who is seeking to right the ship. The pilot says “full left rudder” and the co-pilot puts down the landing gear – the pilot says “drop the passenger oxygen masks” and the co-pilot jettisons the fuel tanks – the pilot says “pull your nose up” and the co-pilot glances toward the ceiling.

Example II – Performing Heart Surgery

A patient is brought into the hospital Emergency Room – problem – patient is suffering from chest pain and possible heart attack. A seasoned doctor and an intern are working the shift together and are immediately called to address the emergency. As the patient is put on the gurney the veteran doctor asks the intern what the patient vital signs are – the intern responds with a blank stare saying “vital signs -what are they?”. The seasoned doctor then asks for the heart rate of the patient and the intern says “does that mean how many beats per minute?” The veteran doctor then requests the “paddles” and the intern responds with “I left them at the cottage”

The point I am trying to make is not about flying a commercial plane or performing open heart surgery. It’s about why there is such a disparity in how and why IT professionals are not compelled or responsible for establishing and applying a common terminology that could be understood and expected to be applied by everyone in the field. Although un-verifiable (even with my “unofficial survey”) I suspect if the IT profession ever took it upon itself to work toward a common terminology it may reduce the number of errors found in applications, it may reduce the time a project team needs to deliver an application to the production environment, it may increase a project teams ability to design an application that meets the user requirements, it may improve the communication and understanding between business subject matter experts and IT practitioners, it may ensure an organizational process could be implemented and relied upon to consistently deliver products, services and operational efficiency.

At the risk of providing the correct answer to the “unofficial survey” question while being perceived as clogging the ever spinning wheels of IT terminology – an “IT Methodology” can be used in the context of both the “noun” and/or the “verb”.

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.

I was invited out to lunch last week by an old friend and colleague. We had worked together at the same organization many years ago and have been able to stay in touch. Once meeting at the diner, we were seated and ordered our meals – then he broke the news. He had recently (4 weeks ago) accepted a senior management position at a reputed fortune 500 company – his role was to guide the project management office (PMO) for the whole organization.

After receiving my congratulations, a somber and concerned look came over his face – he stated “I think I have just made a serious error with regard to my career”.

As we discussed things further I began to gain an appreciation for his statement.  He drew an analogy to a train wreck that gets replayed day after day after day – a perpetual circle of point the finger and lay the blame – without a beginning and without an end.

He began citing a number of instances, the users were in a constant state of wondering why changes to existing applications took so long, the IT application maintenance staff did not have any documentation to scope or verify changes being made, the development staff were creating applications in days without reviewing the development iterations with the user community, and testing (of any kind) was not performed on any of the applications being placed into the production environment. As a result, the work environment became tainted with “watch your behind”, “never trust a user”, “never trust a tech”, etc, etc, etc. Upon completing the description he looked at me with a bewildered look and said “what am I going to do?”.  I asked “what IT methodology is the organization using?” to which he responded “there is no recognized or formal IT methodology being used, every project and maintenance team has their own approach and none of them are documented, none are repeatable and none are communicated our understood by the user community”.

I told him the more difficult the problem the more simplified the solution must be – I suggested he could do one of two things. He could call his boss from his former company and try to get his old job back or he could accept his new organization for what it was and make an effort to turn things around and attempt to point it in the right direction.

He acknowledged my point and we started down another tangent talking about what could be done at his new position to remedy the situation – he told me “the floor is yours” and asked for suggestions on how I would address things. I said my most immediate concern would be the poor (or lack of) communication and lack of trust between the various departments and staff of the organization – poor internal communications is often the root cause for a culture of finger pointing and lack of accountability. Then I mentioned the lack of having a formal (recognized) IT methodology appeared to be the most significant deficiency within the organization.

I went on to explain that although many experts subscribe to the notion that an IT methodology is used to consistently deliver quality applications in a timely manner it can also provide additional benefits to an organization. More specifically, it can:

• provide a common tool and language that organizational staff (business and IT) can utilize for developing and maintaining applications
• create a framework that organizational resources can leverage to perform project management, software development & maintenance, and software testing
• establish a deliverable based and scalable process enabling organizational resources with the versatility they require to be proficient on a multitude of applications in a multitude of environments
• be applied as an operational process (benchmark/standard) that all product and project teams use for delivery – in being a standard process it can be used as the basis for performing reviews and audits to determine how the process is being applied and improved

As we left the eatery he thanked me for getting out to lunch with him and was appreciative that I was able to toss my “two cents” into the discussion. I then asked him if he was going to be calling his old boss back. He smiled with a glint in his eye and said, “no way – there is an organization that has to be saved and I’ve got to start that effort this very afternoon”.

Suffice it to say, I am looking forward to getting back out to lunch with him in a month or so – I am interested to hear how his effort is going and hoping to be able to add another “two cents” – will keep you posted.

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.

Context
From the initial days of Information Technology (IT), practitioners have always recognized the need to establish and apply a suite of industry recognized best practices. One of these best practices is used to develop and maintain computer applications – it is called the cycle of life for software. A number of lifecycles have been developed to address specific disciplines within this cycle of life – examples include Project Management Lifecycle (PMLC), Software Development Lifecycle (SDLC), and Software Testing Lifecycle (STLC).   In all cases, these lifecycles are made up of a number of phases, each containing a predefined set of deliverables.

Software Testing Lifecycle (STLC)
The STLC is used by application development and maintenance teams to test and verify the functionality of an IT application or system – the intent is to ensure a certain degree of quality has been incorporated into the application being delivered.  It is used across an organization and is applied from the inception of a project (development or maintenance) through a successful implementation of the required solution.  Though a multitude of STLC’s exist, they are commonly based on a phased approach, pre-defined deliverables, and standard naming conventions. The STLC traditionally executes in parallel and concurrently with a software development lifecycle (SDLC).   The following provides an overview of the phases within a traditional Software Testing Lifecycle.

Systems Analysis
The Systems Analysis phase is the first phase to be performed within an STLC. It is initiated in conjunction with a project being authorized or approved. Its purpose is to ensure proper and effective planning is applied to the strategic and user acceptance testing effort and activity that will be performed on the application prior to it being placed in the production environment. This includes defining the user acceptance criteria and conditions the user community will apply to assess the functionality being delivered.

Design
The purpose of the Design phase within the STLC is to

1. Ensure proper and effective planning is applied to define the system integration and unit testing efforts to be performed on the application
2. Establish the pre-defined testing criteria and conditions that will be used to evaluate the system integration and unit testing results
   

Build
The Build phase is an iterative process within the STLC. Its purpose is to ensure all the technical code that has been developed reflects the pre-defined unit testing criteria established during the Design phase - the following steps are applied

1. Apply and execute the pre-defined unit testing criteria (defined in the Design phase) against the technical code that have been created 
   
2. Identify and document unit testing deviations (expected results versus actual results)
3. Communicate unit testing deviations to the development team
   
4. Retest revised technical code against the unit testing criteria
   
5. Confirm that all the pre-defined unit testing criteria have been satisfied
6. Promote the authorized technical code from the unit test environment to the system integration test environment

Test
Like the Build phase, the Test phase is an iterative process within the STLC. Its purpose is to ensure all the technical code that has been developed reflects the pre-defined system integration testing criteria established during the Design phase – the following steps are applied 

1. Apply and execute the pre-defined system integration testing criteria against the technical code that have been created
   
2. Identify and document system integration testing deviations 
3. Communicate system integration testing deviations to development team 
4. Retest revised technical code against system integration testing criteria 
5. Confirm that all the pre-defined system integration testing criteria have been satisfied 
6. Promote the authorized technical code from the system integration test environment to the user acceptance test environment

Release
Just like the Build and Test phases, the Release phase is also an iterative process within the STLC. Its purpose is to ensure that what has been developed meets the user acceptance testing criteria established during the Systems Analysis phase – the following steps are applied  

1. Apply and execute the pre-defined user acceptance testing criteria against the technical code that has been generated
2. Identify and document user acceptance testing deviations 
3. Communicate user acceptance testing deviations to development team
4. Retest revised technical code against the user acceptance criteria
   
5. Confirm that all the pre-defined user acceptance testing criteria have been satisfied
   
6. Promote the authorized technical code from the user acceptance test environment to the production environment
   

The STLC can be applied by development teams to create applications – it can be applied by support teams to maintain applications.

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.

In a recent scan through Google I came across a number of the articles comparing the “waterfall” delivery approach to the “agile” delivery approach. Paraphrasing, the one article described “agile” as a fad – the other article praised “agile” as the next best thing since sliced bread.  The more I read of these articles, the more obvious it became that something in the IT lore had been lost somewhere along the way – the industry as a whole appears to be in a conscious effort to forget what was learned yesterday only to reinvent it again tomorrow. What seems to have been lost in both articles is the reality that the whole “waterfall/agile” discussion/debate has been going on for over 50 years.

Though proponents of these (“waterfall” versus “agile”) delivery approaches differ in perspective, the ardent advocates of each frequently fail to recognize the whole “waterfall/agile” debate is merely an extension of the ever present and necessary exercise every organization undergoes to assess and verify the value and contributions of their IT assets (staff, hardware, software).  Put another way, the discussion gets down to determining how much formality and structure an organization requires to ensure its IT assets are effectively contributing value to the delivery of its products, services and internal operations. We need look no further than a couple of examples. Citing NASA of the 1960’s, the Apollo missions required a great deal of rigor to send the first space craft to the moon – a formal methodology  was mandatory to ensure the astronauts were able to reach their destination and arrive home safely. Citing the teens of the early 1980’s when building games on their newly purchased Commodore 64’s - functionality was created without restriction – to them, formal methodology was a derogatory term viewed as a harness encumbering their creativity and productivity. Though we may have recently been lulled into believing the fundamental question is about "waterfall" versus "agile" we somehow have forgotten that these discussions (structure versus non-structure) have existed and been ongoing between IT practitioners since the inception of IT.

At the risk of stating the obvious, it is important that IT users and practitioners always remember there is a difference in the term” IT methodology” and how it can be applied. In one sense, “IT Methodology” is a “noun" - a path that can be used to get from a starting point to a destination (road from Boston to New York) - the road is constant and unchanging (in this context “IT Methodologies” include RUP, PMI, QAIassist, etc). In another sense, “IT Methodology” is used as a "verb" - how a project team uses the path (noun) to get to its destination (delivery approaches include waterfall, agile, spiral, RAD, etc).

For the sake of the IT industry, I can appreciate and promote the need to have an ongoing debate/discussion on the merits (pro's and con's) for each of the various delivery approaches (verb - waterfall, agile, RAD, spiral), however, the reality is that if one (waterfall, agile. etc) of these delivery approaches was ever proven to be more beneficial and successful than any of the other delivery approaches it would be being utilized by every project manager on every project by every organization. That stated, we must not ever forget that each and every one of these delivery approaches as its own merits but must remain subservient to the business and the business need (applying waterfall or agile for the sake of applying waterfall or agile must always remain a non starter).

Reflecting back on the early days of my IT career, I remember the various organizations I had the privilege to work for. On the one hand there was the "structured organization" that required a formal and structured delivery approach (ie documentation, formality, formal deliverables, etc) - a formal repeatable IT methodology (noun) was required and relied upon to consistently deliver quality applications on time and budget, it was a predictable repeatable process in and of itself. On another hand, there was the "let’s get the application out the door yesterday organization" that had a need to complete applications to meet the timeliness to market expectations on an ongoing basis (ie no time to complete documentation, no deliverables, no ongoing application support, no formal testing). My point is not to promote which of these delivery approaches or organizations was more successful, but rather, that every organization has various business needs and those needs (as part of the culture) will influence and define what delivery approach (waterfall, agile, RAD, etc) can and should be used and whether or not a formal “IT methodology” (noun - RUP, PMI, QAIassist, etc) would bring additional increases to the IT value equation.

All that said, I am hoping this article can provide users and IT practitioners a context and backdrop they can reference to continue discussing how IT tools, techniques and practices can best be leveraged to deliver increasing IT value to our ever growing client base.

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.

(the last of the Preaching to the Choir series...)

IT Methodology – Corporate Interfaces

In some organizations the following operational infrastructure (bodies) may exist. They interface with the IT Methodology - Organizational Audiences to contribute to the delivery and support of an IT methodology.

Process/Project Management Office (PMO)
In some organizations a group of experts in the fields of industry recognize standards, methodologies, best practices, quality frameworks are assembled for the purpose of guiding organizational process improvement, change management and quality initiatives. They normally report to Senior Management and are accountable for defining and implementing organizational IT methodologies, policies, processes, guidelines and “best practices”. The PMO are traditionally deemed as the “organizational owners” of all IT methodologies and are responsible for the creation, institutionalization, training and support of these methodologies.

Corporate Training Staff
In some organizations a group of resources are dedicated to delivering overall training (including IT methodologies) to organizational staff. They are responsible for ensuring corporate training standards exist and are applied (including IT methodology training) to the delivery of all corporate training. The training staff collaborate with the PMO to guide the development and delivery of the IT methodology training needs.

Communications Staff
In some organizations a number of resources are dedicated to developing and overseeing all internal and
external communications – including the status and progress of PMO initiatives. These resources are accountable for developing and applying communication strategies and plans to ensure the “proper” message is consistently being delivered. These resources work with the PMO to ensure all organizational staff remain up to date and informed on the progress of the IT methodology implementation.

Corporate Quality Assurance/Governance Resources
In some organizations a team is assembled to monitor how the organizationally approved processes, standards, and IT methodologies are being applied. These resources work with IT staff and project team members to support the implementation of the approved corporate processes, standards, and IT methodologies – they usually have an independent reporting structure direct to organizational Senior Management. These resources use an IT methodology as the basis for performing process audits and reviews with the project teams. The audits consist of checking to see if and how the pre-defined deliverables of the IT methodology are being applied by the project teams. The underlying principle is that “quality” will be incorporated into the end product or system/application if the IT methodology has been effectively applied.

Wrap Up
An IT Methodology is a mechanism that can be used to consistently deliver quality applications on time and within budget. It provides benefits and support to a number of organizational roles that are responsible for delivering IT efficiency and ROI.

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.

(continuing from the previous post...)

IT Methodology - Project Audiences

This audience traditionally views a methodology as a tool they can utilize to ensure they can deliver and support IT projects.  As a tool, a methodology affords this audience access to a pre-defined structure, lifecycles, work products and deliverables that can be applied to ensure the project is properly planned, resourced, and executed.

Business Resources (Analysts)
Business staff are the individuals responsible for understanding the organizational products and services being delivered through day to day operations. They are the “business experts” that are responsible for ensuring all the required business functionality is available in the products and systems/applications being delivered and maintained by the IT resources. An IT methodology provides the business resources the mechanism to articulate and contribute their business knowledge into the requirements that will be used to develop the product or system/application. An IT methodology also provides the Business Analysts an understanding of how the system/application will be built (deliverable wise) and establishes the necessary documentation to ensure the product they are receiving can be tested and maintained to reflect the business requirements they have defined.

IT Project Managers
IT Project Managers are responsible for delivering products and systems/applications to the business stakeholders and user community. They plan, lead and manage a project from project startup through implementation. They are accountable for ensuring the product or system/application adheres to the schedule, cost and quality demands of the project stakeholders. An IT methodology is the tool they leverage to ensure the proper resources and skills are available to complete the project, the business requirements are incorporated into the final product, the final product serves the business need, and the project is completed on time and within budget.

IT Application Development & Support/Maintenance Teams
The IT application/system delivery and support resources are accountable for designing, delivering
and maintaining the functionality of products and applications/systems. These resources are
responsible for delivering and maintaining business systems/applications that provide operational staff the necessary functionality to deliver products and services to the client. Examples of these roles can include system architects, functional architects, database administrators, team leaders, systems analysts,
system programmers, system testers. These resources rely on an IT methodology to pre-define the deliverables (specific work products) the project team will be completing to deliver the project.   

IT Application Testing Teams
The IT Application Testing Teams are accountable for ensuring the product or system/applications being delivered by the IT Application Development & Support/Maintenance teams align with the authorized business requirements and that the business requirements address the business need. These teams are frequently sub-divided into addressing Unit Testing, Integration Testing and User Acceptance Testing. These resources rely on an IT methodology to establish the necessary documentation and pre-defined testing criteria that will be used to validate the functionality being delivered in the product or system/application.
 

 Until next time...

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.

Originating in the early days of information technology (IT), IT methodology has always acted as the “rope” in the tug of war between unstructured chaos and structured discipline. On the one side, the IT resources with their ongoing want to explore the newest technical alternatives and seeking the free range to develop without boundaries. On the other side, the business owner’s seeking to obtain value from their IT resources and the users of products/applications wishing to obtain the business functionality they require to deliver products and services to their clients.

Somewhere in the middle a number of IT methodologies and lifecycles (i.e. project management, software development, software testing) have evolved aiming to provide organizations with a set of tools they can rely on to consistently deliver products and projects on time and within budget.  Applicable for all (small, mid-sized, and large) organizations, an IT methodology can have a beneficial and far reaching effect for multiple audiences across any organization.  These audiences will be broken up into three separate posts...so we will start off with the first one:

IT Methodology - Organizational Audiences
This audience traditionally views a methodology as a process that can be leveraged to ensure consistency in the timeliness, quality and costs of delivering and supporting IT applications.  As a process, a methodology also affords this audience the structure, repeatability and environment to effectively apply governance and continuous process improvement throughout their organization.

Senior/Executive Management
Senior Management is responsible for developing and administering the strategic direction of the
organization. With regard to IT efficiency, Senior Management are searching for ways to improve the bottom line and make decisions on everything from IT budget to IT tool suite selection to outsourcing of IT functions. From this perspective, Senior Management understands that an IT methodology is a tool that can be leveraged to increase the efficiency of IT, establish a common process for developing and maintaining applications, and ensuring a degree of quality is being built into every product and application. Senior Management are more interested in achieving greater efficiency and delivering value than knowing the technicalities and dynamics of a methodology – they seek greater consistency, efficiency and cost effectiveness.

Line Management (Business)
Business Managers are responsible for the delivery of products and services to the user
community (internal and external). From this perspective, Business Managers recognize their ability to deliver products and service is dependent on the viability, reliability and applicability of the applications/systems to be used by their staff. Business Managers recognize the importance of having their staff contribute to the development and maintenance of their applications and view an IT methodology as a mechanism their staff can utilize to ensure the business requirements are defined and communicated to IT project development or maintenance teams. Within some organizations, the Business Managers are responsible for authorizing and oversight of the IT Budget – in the majority of these organizations the Business Managers are insistent that an IT methodology be utilized for all IT development and maintenance work.

Line Management (Information Technology)
IT Managers are responsible for the delivery and support of applications/systems that contribute
to the operational performance of the organization and its ability to deliver products and services. IT Managers monitor the technical architectures, tool suites, software products to ensure IT staff are positioned to deliver products, services and support to the business side of the house. The IT methodology affords IT Management the reassurance of predictability – they can be confident the methodology will provide project and maintenance teams the mechanism to consistently deliver quality applications on time and within budget. Applying a common IT methodology also provides IT Management with the flexibility to manage and re-direct their staff across multiple organizational IT priorities.

Stay tuned for the next two!

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.

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.

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

How is it possible that some organizations consistently perform at such high rates while other organizations struggle to deliver?

In this 30 minute webinar, Cameron Watson, President of QAIAssist, provides a conceptual overview of the terms "Operational Effectiveness" and "IT Efficiency," and discusses how organizations can apply these key concepts in order to optimize product development, operations and delivery. Reserve your seat today!

Register: Operational Effectiveness & IT Efficiency Webinar

Wednesday, June 30  |  8:00 AM, Pacific Time

 

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

Context

From the initial days of Information Technology (IT) practitioners have always recognized the need to establish and apply a suite of industry recognized best practices. One of these best practices is used to develop and maintain computer applications. This is the cycle of life for software. 

A number of lifecycles have been developed to address specific disciplines within IT - examples include Project Management Lifecycle (PMLC), Software Development Lifecycle (SDLC), and Software Testing Lifecycle (STLC).   In all cases, these lifecycles are made up of a number of phases, each containing a set of deliverables. 

Software Development Lifecycle (SDLC)

The SDLC is used by application development and support teams to develop and maintain computer applications and systems.  The SDLC is usually applied across an entire organization and is used from the inception of a project through to a successful implementation of the required solution - in the majority of organizations, the SDLC is executed and monitored using an accompanying Project Management Lifecycle (PMLC).  Though a multitude of SDLC's exist, the majority of them rely a phased approach, pre-defined deliverables, and standard naming conventions. The SDLC executes in parallel and concurrently with a software testing lifecycle (STLC).   The following provides an overview and explanation of the sequenced phases of a generic software development lifecycle (SDLC).

Systems Analysis

The Systems Analysis phase is the first phase to be performed within an SDLC. It is initiated only and in conjunction with a project being authorized or approved. Its purpose is to ensure the requirements to satisfy a business need have been identified and translated into a notational form or models. Once documented, project teams (business and technical staff) utilize the requirements to ensure a common understanding is achieved and to verify the requirements are attainable.  As an iterative process, the Systems Analysis phase ensures the project team members are working together to define and clarify the business need and promoting alternatives that could be utilized to address the business need.

Design

The Design phase ensures the application is designed according to the authorized requirements generated during the Systems Analysis phase. The Design phase focuses on the refinement and further granularity of the data, application, and technology models defined in the Systems Analysis phase and incorporates other factors that must be considered in designing the solution (e.g. data and non-functional requirements, testing strategy). The solution designed is refined to a level (ie functional specification) where individual software, hardware and data components are defined and documented. When this phase is complete, it will be possible to generate comprehensive time and resource estimates for delivering the application and the necessary business functionality.

Build

The Build phase ensures the following:

1. The application is being built in accordance with the business requirements that were prepared and refined during the Systems Analysis phase
2. The technical and functional standards, as well as design elements of the business solution prepared during the Design phase are used as the basis for developing and testing the product. 

The aim of the Build phase is to produce readable, testable and maintainable code for the application in a non-production environment.

Test

The Test phase ensures:

1. The technical code created during the Build phase adheres to the business requirements that were developed and  evolved since the beginning of the project
2. The technical code adheres to the design standards prepared during the Design phase. 

The aim is to ensure the code built in a non-production environment is viable and can be tested by the end users to assess its ability to satisfy the business need.

Release

The Release phase ensures the application has been satisfactorily tested and satisfies the business need. Once satisfying these criteria the application can be placed into the production environment and utilized by the user community in a production environment.

 

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

Context

From the initial days of Information Technology (IT), practitioners have always recognized the need to establish and apply a suite of industry recognized best practices. One of these best practices is used to develop and maintain computer applications. This is the cycle of life for software. 

A number of lifecycles have been developed to address specific disciplines within IT - examples include Project Management Lifecycle (PMLC), Software Development Lifecycle (SDLC), and Software Testing Lifecycle (STLC).   In all cases, these lifecycles are made up of a number of phases, each containing a set of deliverables.

Project Management Lifecycle (PMLC)

The project management life cycle (PMLC) is used to initiate, plan, oversee and deliver IT applications and systems from inception to fully operational in a production environment.  It is used across an organization and is applied from the beginning of a project (development or maintenance) through a successful implementation of the required solution.  Though a multitude of PMLC's exist, they commonly rely on and are executed using a "phased" approach, pre-defined deliverables, and standard naming conventions. The project management lifecycle (PMLC) traditionally acts to guide the software development lifecycle (SDLC) and the software testing lifecycle (STLC).  

The following provides an overview and explanation of the sequenced phases of a generic project management lifecycle (PMLC).

Initiate

Initiate is the first phase to be performed within the project management lifecycle (PMLC). It is the process of formally recognizing that a project exists and has been authorized to continue. The purpose of this phase is twofold :

• First, to assess and determine a business need.
• Second, to translate high-level business requirements into a set of requirements from which the project team will build the product and confirm the requirements can be fulfilled.

This iterative process is lead by the project manager who requires input and expertise from both business and technical IT resources assigned to the project. 

Plan

The Plan phase is executed upon the authorization of a project. It is an iterative process used by a project manager to devise, maintain and execute a workable plan to ensure the business solution is effectively implemented. The workable plan must address:

• Project scope
• Resource requirements, project team roles
• Deliverables to be prepared throughout the project
• A schedule to define how and when the project will be completed
• The activities to be applied to ensure quality is incorporated into the implemented solution

Execute and Control

The Execute & Control phase is an iterative process that aims at coordinating the activities of the project team resources to ensure the project can be completed according to the project plan. The progress of the project activities are monitored against the project plan and the appropriate corrective action are taken when the project is deviating from the project plan. The Project Manager prepares and utilizes a number of specific deliverables to ensure project procedures are available to the project team, the project management deliverables are maintained throughout the life of the project, deviations to scope, schedule and resources are addressed in a timely fashion.

Closure

Closure is the final phase of the project management lifecycle. Its purpose is to document a true reflection of how the project evolved from start date through to its completion so that future projects can benefit from the knowledge and experience gained on the project. Future project teams can then leverage this knowledge to increase the efficiencies on delivering business solutions to their clients.

 

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