IT Project Management Software & Efficiency Solutions : project management software

Deliverable vs. Activity

CameronWatson — Wed, 04 Apr 2012 16:31:00 GMT

As the industry leader in delivering IT Methodology related webinars, it is sometimes interesting to take a step back and do a little analysis on the delivery of our sessions. For the majority of our IT Methodology webinar sessions we make a point of sending out a survey to those who have attended. In reviewing the comments and feedback of the webinar attendees, it is interesting to see how many participants are seeking to obtain more clarity on the difference between a deliverable and an activity - the following narrative attempts to address this question.

To properly discuss the concept of deliverables/artifacts/work products it is important to establish a context and a basic definition. First, we must understand and accept that these terms (deliverable/ artifact/work product) are fundamentally synonymous in nature – each and all of these terms can be referenced as a specific unit of work, each and all of these terms can be referenced as having a specific purpose, each and all of these terms can be referenced according to a pre-defined quantifiable criteria. These terms and their usage are loosely applied across and throughout the IT industry – a deliverable at one organization can have the same meaning and purpose as an artifact at another organization or a work product at another organization.

In establishing that premise (deliverable, artifact, work product are fundamentally synonymous) we are able to identify the following characteristics common to deliverables/artifacts/work products.

• each is tangible (can be see and touched)
• each has a specific purpose (i.e. Project Charter, Business Case, Testing Strategy, etc.)
• each has a unique and predefined set of criteria (informational requirements to be completed)
• each is a specific unit of work
• each can be assigned to a specific project team resource
• each can be reviewed & approved independently
• each can be reflected on a project schedule (WBS)
• each can be placed under configuration management throughout the life of a project
• each can be assessed (peer review and quality assurance)
• each can be referenced to enable future application maintenance/modification

Using these characteristics we are able to distinguish between deliverables/artifacts/work products and activities. Let us assume we are going to build a house

Deliverables/Artifacts/Work Products Activities

- Blue Prints                                                                          - meeting with the Architect to review the blue prints
- Basement Floor Poured                                                     - mixing the concrete for the basement floor
- Windows Installed                                                              - purchasing the wood to build the windows

Citing this “building of a house” allows us to draw comparisons in how various IT projects are defined, planned, executed, controlled and implemented.

Organizations and project teams that apply the concept of “deliverable/artifact/work product” are more likely to develop and maintain applications using a structured, predictable, repeatable approach - resources become familiar with their roles, the user community participates in the development and testing of the application, and the project team delivers to expectations. Conversely, organizations and project teams that rely on developing applications through performing “activities” do not have the same luxury of applying a structured, predictable, repeatable approach – “activities” change between projects resulting in changing roles and responsibilities, varying participation from the user community and unpredictability in how the applications are going to be delivered.

Though the IT industry has not yet established the best or ultimate methodology/lifecycle for delivering applications and projects, it has evolved to understand that a project team that recognizes and applies the concept of deliverables/artifacts/work products has a higher likelihood of delivering a quality application/project on time and within budget. Conversely, a project team that does not apply the concept of deliverables/artifacts/work products is more prone to spending time and resources on performing “activities” that may not result in delivering the application/project on time and within budget.

Cameron Watson

Cameron Watson is the President of QAIassist. QAIassist is the industry recognized benchmark in information technology (IT) methodologies for small and mid-sized business ( SMB’s ) – including the certification and support of practitioners delivering QAIassist IT Methodology solutions. Article authored by Cameron Watson – President of QAIassist. Visit QAIassist's website—www.qaiassist.com.

“IT Methodology” – what’s in a name?

CameronWatson — Wed, 07 Dec 2011 23:30:00 GMT

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.

IT Methodology - a Career Changer?

CameronWatson — Tue, 08 Nov 2011 16:32:00 GMT

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

The Cycle of Life: Software Testing

CameronWatson — Mon, 29 Aug 2011 15:49:00 GMT

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

Ensure proper and effective planning is applied to define the system integration and unit testing efforts to be performed on the application
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

Apply and execute the pre-defined unit testing criteria (defined in the Design phase) against the technical code that have been created
Identify and document unit testing deviations (expected results versus actual results)
Communicate unit testing deviations to the development team
Retest revised technical code against the unit testing criteria
Confirm that all the pre-defined unit testing criteria have been satisfied
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

Apply and execute the pre-defined system integration testing criteria against the technical code that have been created
Identify and document system integration testing deviations
Communicate system integration testing deviations to development team
Retest revised technical code against system integration testing criteria
Confirm that all the pre-defined system integration testing criteria have been satisfied
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

Apply and execute the pre-defined user acceptance testing criteria against the technical code that has been generated
Identify and document user acceptance testing deviations
Communicate user acceptance testing deviations to development team
Retest revised technical code against the user acceptance criteria
Confirm that all the pre-defined user acceptance testing criteria have been satisfied
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

IT Methodology – How much is too much ?

CameronWatson — Wed, 03 Aug 2011 20:06:00 GMT

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

Preaching to the Choir - Part I

CameronWatson — Tue, 28 Jun 2011 17:55:00 GMT

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

The Cycle of Life: Project Management -by Cameron Watson

Angela Watford — Tue, 01 Jun 2010 18:09:00 GMT

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

IT METHODOLOGY - A Long and Winding Road -by Cameron Watson

Angela Watford — Tue, 01 Jun 2010 18:06:00 GMT

The ancient Greeks first coined the term "methodos" - its definition meaning "path." They applied this term in various contexts - as a noun "a path that could be followed to reach a destination" and a verb "the journey to be taken along a path." Though several millennia have passed since the ancient Greeks first used the term, it is still applicable in today's world of Information Technology (IT) - it is called "IT Methodology".

As simple as the term IT Methodology may appear, it is intriguing to see how it can be applied in such a variety of contexts, by such a wide array of experts, to such a diversified set of audiences - it can be applied to project management, software development, and software testing lifecycles. Suffice it to say, this lack of clarity and context has introduced its own share of confusion, misunderstanding, miscommunication and misadventure.

Let's provide a context around the term "IT Methodology"

IT Methodology - the road you take

As a noun, "methodos" can be equated to a road on a map. For example, the highway that connects Boston to New York, it has a beginning and an end. It is tangible. It has a predefined set of destinations that must be passed along the way, such as a city, a town, a river, a crossroads, etc. The road is constant and indifferent to how many vehicles use it, what vehicle is to be used, how many people are in each vehicle, how fast each vehicle travels or how many times the vehicle starts and stops during its journey.

As a noun, "IT methodology" is much the same as the road. It has a beginning and an end. It has a pre-defined set of criteria that must be passed along the way: lifecycles, phases, deliverables, work products, etc. It is consistent and indifferent to how many projects utilize it, the scope of each of the projects, the size of the project team, the speed at which a project team completes it, the number of iterations a project team employs. Examples include ITIL, Rational Unified Process (RUP), CoBit, and QAIassist Integrated Methodology.

IT Methodology - how you travel that road

As a verb, "methodos" describes how the road will be used. Travelers using the road between Boston and New York have the option to travel in the vehicle of their choice at the speed they wish, and to make as many stops as they wish along the way.

As a verb, "IT Methodology" is the delivery approach a project team takes to get to its destination, a completed project. Examples of delivery approaches include Waterfall, Spiral, Rapid Application Development (RAD), Agile, Joint Application Development (JAD), and Scrum.

IT's not all Greek

Though the effort to understand the term "IT methodology" may appear to be long, winding and Greek to many, there is a difference between the "road" used to get to the destination and the "activities" that will be performed while on the road and heading to the destination.While most people will agree that it's important to agree on the goal of a project, we tend to forget that agreeing on how we will achieve that goal is just as important.

Cameron Watson, President, QAIAssist