IT Project Management Software & Efficiency Solutions : IT project managers

Snow White & the Seven Dwarfs – The Most Important IT Methodology Deliverable?

CameronWatson — Fri, 06 Jan 2012 22:47:00 GMT

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.

“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

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

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 II

CameronWatson — Tue, 05 Jul 2011 16:02:00 GMT

(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