The Project Management Method and the SDLC

Many people are confused over the difference between a project management method and the System Development Life Cycle. Some believe a project management method is a subset of the SDLC and some believe the inverse, that the SDLC is a subset of a project management method. The truth lies somewhere in between. In terms of importance to a project, the SDLC and a project management method are co-equals which complement each other. Together they harmonize to form a complete methodology for delivering high quality products to our customers that meet or exceed their expectations. Neither can stand on its own to deliver high value to the business. They each have different roles in support of business initiatives. Throughout the life cycle both of these methods work together to achieve business goals, drive the value equation and progress organizational maturity. Though their activities differ greatly, they interrelate and harmonize to produce superior results.

A project management method provides detailed instructions for the discipline of planning, organizing, controlling, reporting and managing project resources to successfully complete project goals and objectives. It includes all of the activities for managing a project. A project is temporal in nature. It has a defined beginning and end. The project management method begins with project inception and closes when its product is delivered. When a project is over, the project manager moves onto something new.

The SDLC provides a framework that describes the activities performed during each phase of a systems development project. The SDLC is about quality, consistency and product delivery. It is about the realization of a product’s requirements. Products are of a more permanent nature than a project because products continue to exist long after the project that delivered it has closed. Therefore, the SDLC’s framework provides guidelines for supporting the product post production. Guidelines include practices for knowledge transfer, training, document turnover, maintenance and on-going support. When a product is to be retired, the project management method takes over to sunset the system. It is a full circle in a system’s life.

Project management is often expressed in terms of the constraints of scope, time and cost. This is also known as the project management triangle. Each side of the triangle represents a constraint. No side can be changed without affecting the others. At one time, “quality” or “performance” was considered a component of scope. The model has since been refined to delineate quality as a fourth constraint.

Time is the period available to complete a project. Cost is the project’s budget. Scope is what must be done to complete the project's deliverables. The three constraints often compete with each other: scope creep means increased time and higher cost, a tight time frame may mean higher costs and less scope, and a tight budget may mean less time and reduced scope. Quality may be at risk if there are changes to any of the constraints.

To demonstrate the complementary nature of the SDLC to project management, I’ve contrived the SDLC triangle. Earlier I said the SDLC is about quality, consistency and product delivery. Quality, consistency and product delivery are the outputs of a defined, managed, measurable, repeatable and reusable set of processes and practices. The processes and practices form the core framework of the SDLC. Where a project is defined by its constraints, the SDLC is defined by its freedoms and empowerment. The SDLC empowers a project team to choose from among several approved pathways to deliver the highest quality products possible in the shortest amount of time and at the lowest possible cost.

Scope is a constraint that SDLC processes liberate by managing scope creep. Scope creep is a project killer. Let’s be clear, project scope will change during the course of a project. That’s because business priorities are fluid and may drive changes in projects so that evolving current needs are met. It’s how we manage scope that’s important. We’ll never be able to eliminate scope creep, but we can manage it effectively so it doesn’t become the constraint that kills our project. In many ways, managing scope creep begins with the project’s business analyst.

Consistency of process helps keep the cost constraint under control by practicing repeatable, measurable and defined algorithms. Let’s be pragmatic. Whenever we practice something, we get good at it. It doesn’t matter if we’re talking about music and the arts or sports or anything else. The old adage is “Practice makes perfect.” If we do something the same way over and over again, not only will we get good at it; we’ll find ways to improve what we are doing so we can do it faster, better and cheaper.

The schedule constraint is complemented by the SDLC’s timely delivery of a quality product that meets or exceeds customers’ expectations. If we manage scope creep effectively and are consistent in our ability to repeat and improve our processes, not only will we deliver a product on time, there may even be enough wiggle room in the schedule to address lower priority items or deliver the product ahead of the due date.

The complementary relationship between the SDLC and a project management method cannot be denied. They do not compete against each other.

IT Governance and the SDLC – Part 2: Upfront Requirements Elicitation

When discussing investment opportunities at governance meetings, senior managers invariably ask: “How much will the project cost us?” In the early phases of opportunity talks many IT leaders respond with the “SWAG” (Scientific Widely Aimed Guess) based on experiential supposition. Later, after governance approves a deeper investigation into the cost, IT leadership returns to governance with a slightly more predictable estimate known as a ROM or Rough Order of Magnitude, based on nothing more than executive level discussions, the research they’ve done from talking to vendors and presuming what resources will be needed. They don’t even have enough information at this point to distribute a formal Request for Information (RFI). Returning to governance, they supply a statement of work documenting what they believe is required, a Return on Investment (ROI) calculation based on the ROM, resource plan and projected schedule. If all goes well, governance is convinced of the projected derived business value and ROI and approves the project—all based on conjecture.

Nobody up to this point has gathered any of the actual requirements from the business users. The discussions thus far have all been very high level. This is highly ineffective IT Governance in action. You may also say this is IT Governance inaction. Ineffectual governance processes often lead down the path of conducting requirements elicitation and analysis early in the project lifecycle but only after the project is approved and funded. This is always a bad decision and one that leads to more problems for IT leadership down the line.

When Business Analysts start the requirements elicitation process after the project approval and kick-off, it doesn’t take too long to discover the original investment estimates were way too low. Now that the true business requirements are known, the project team realizes the scope to deliver the necessary functionality to the business is much broader than they first thought. As the project proceeds several months down the road, IT leadership goes back to governance and asks for more money to complete what they started and explain why the original timeline has to be extended. Governance either reluctantly responds to the increase in funding or trashes the project altogether. Whatever the case, IT leadership loses credibility with senior management.

Do you think this scenario is farfetched? It’s not. I’ve worked in organizations that have followed this exact process and have witnessed it time and time again. Senior leadership’s loss of trust and credibility in the IT organization is always the result. It is a difficult if not nearly impossible obstacle to overcome. Trust and credibility can be regained over time, but it takes a lot more than continuing with the same processes that got you into trouble in the first place. It often requires replacing the senior IT staff and embarking upon a long journey of IT business process transformation.

The truth is that questions surrounding IT investment and prioritization cannot be fully answered until at least one practice area of the SDLC[1] is executed and at least partially concluded. That area is performing the processes and practices governing requirements elicitation and analysis. This may also be known as a feasibility study. The question that now comes into play is “How deeply must I capture the requirements at this phase?”

The answer is variable depending on the project, but as a general rule of thumb, if we apply the Pareto principle to investment value and requirements, the resulting theorem says, “80% of the business value of an investment comes from 20% of the requirements.” This tells us that we don’t have to capture all of the requirements in the initial pass. We only need to capture the major requirements in a quantity sufficient to extrapolate a fairly accurate resource allocation and cost projection. A common practice is to pad IT project cost estimates with an additional 25% contingency anyway. By executing the requirements elicitation upfront, before project approval, you’ll provide much more accurate cost estimates, lower your contingency padding and reduce the chance of project overruns.

---

[1] Systems Development Life Cycle.

IT Governance and the SDLC – Part 1

What has the SDLC got to do with IT Governance?

It has long been the tradition of board-level executives to defer all key IT decisions to the company’s IT professionals. The truth is that many board-level executives don’t understand IT well enough to manage IT effectively; and IT professionals don’t understand business initiatives well enough to decide how to invest in them. Deferring key decisions to the IT staff often leads to disconnects between the board’s strategic goals and real business initiatives and the investments IT makes. It leads to frustration at all levels.

IT governance is a business-driven function which focuses on the investment and prioritization of IT systems, their performance, risk management and enhancing a company’s competitiveness. It’s about ensuring IT investments harmonize with the enterprise’s strategic priorities. It’s about IT demonstrating to senior leadership they are receiving acceptable value in return for making IT investments.

In June of 2005, I attended a summer session on IT Governance and Leadership at the MIT Sloan School of Management Center for Information Systems Research (CISR) in Cambridge Massachusetts. The course was facilitated by Peter Weill and Jeanne W. Ross. Peter is the director of CISR and Jeanne is a Principal Research Scientist. Together they authored the book “IT Governance” published in 2000 by Harvard Business School Press. The book is about “How Top Performers Manage IT Decision Rights for Superior Results.” It is written for “concerned officers of the enterprise (CEO, CFO, COO, and other senior managers) looking for practical guidelines to improve their returns from IT investments.”

According to Weill and Ross, “Top-performing enterprises succeed where others fail by implementing effective IT governance to support their strategies. For example, firms with above-average IT governance following a specific strategy (for example, customer intimacy) had more than 20 percent higher profits than firms with poor governance following the same strategy.”

All companies have some sort of IT governance. Effective IT governance includes well defined and documented processes for work uptake, decision making, budgeting and estimating resources, approvals, IT value realization, project reporting and change management. Many IT governance committees are comprised of the senior most leaders from all strategic areas of the business, not just IT leaders. With a finite enterprise budget, there is competition for capital project dollars. There must be a governance process in place to assure that the right projects are getting the right amount of investment at the right time to improve bottom line profitability and shareholder value.

Weill and Ross assert that effective IT governance answers three questions:

1. What decisions must be made?
2. Who should make these decisions?
3. How will we make and monitor these decisions?

To further explain the first question, they say, “Every enterprise must address five interrelated IT decisions: IT principles, IT architecture, IT infrastructure, business application needs, and IT investment and prioritization.”

The SDLC figures prominently in executing the answers to all of the interrelated decisions above with the lone exception of IT principles. IT principles are subordinate to corporate principles established at the enterprise level. They support or enable strategic company business goals, guide the development and implementation of the SDLC and steer the decision making process in the other four areas. We’ll explore the linkage between IT Governance and the SDLC further in my next post.

Taking AIM at Organizational Change Management – Part 2: Cultural Fit

To fully realize a change management strategy, make sure the change fits your culture. You’ll also need detailed reinforcement and communication plans. Cultural fit is as individual as companies themselves. Every organization has its own variety of cultures and sub-cultures. Most businesses establish a target company-wide culture through their mission statement, vision, values and leader behaviors. Senior management demonstrates the cultural norms as they interpret these tenets. How these creeds flow down and become the organization’s cultural norms may differ from group to group within a company just as strategic goals start at the top and evolve to fit each group’s contribution to the overall strategy. There is no one-size fits all approach to cultural fit. There are tactics however that can guide your moves.

First, define the cultural dimensions of each group impacted by your change. For the SDLC, this is your entire IT organization, senior management and your business users and customers. The SDLC represents a broad sweeping change. It is important to first focus on the “low hanging fruit.” Exploit the aspects of the change that produce the highest yield and lowest risk. Take advantage of any opportunity to lead with results rather than rhetoric. Altogether avoid or reduce the initiatives that are more about image and not reality.

Each of your target groups need to have sponsors who are capable of identifying the cultural characteristics that support the change as well as the values, behaviors and “unwritten rules” that resist the change. Positively reinforce and emphasize the behaviors that support the change. Provide high visibility rewards and recognition for attaining the desired state.

Regardless of how effective your positive reinforcement is, you will face cultural resistance. Someone once asked me, “Why is it necessary to have a company-wide SDLC? We all do things now that are effective for us, why change?” This individual was a member of one of the working teams building and vetting the SDLC processes. His question caught me off guard. He didn’t understand the big picture even though he was serving as a change agent and involved with the very construction of the SDLC. As I thought things through, I realized this question is a direct result of my failure to effectively communicate the vision to the change agents.

For each major source of cultural resistance, you need to discover the answers to these three questions:

1. What are the values, behaviors and “unwritten rules” that are motivating the resistance?
2. What is it about the culture that reinforces the “unwritten rules?”
3. What is it about our system that rewards the “bad” behaviors?

Armed with this intelligence, you can then work to define and implement specific changes that reduce or eliminate the cultural dimensions that reinforce change adversity and execute those that reward the new behaviors. Develop a positive reinforcement plan that is stronger than the motivation to keep the status quo. It requires significantly more sponsorship attention, discipline and stamina to inspire a group to move from “discomfort and resistance” to “opportunity and need.” The sponsors must “walk the talk” and visibly display the new behaviors even if they are individually painful.

Consider offering financial rewards as part of your positive reinforcement plan such as a salary increase, bonus, prize or perk for demonstrating the new behaviors. Apply the positive rewards immediately after observing the performance of the new behaviors. Celebrate early successes and wins. Do whatever you can to make it more difficult to continue to operate in the old state.

Build an effective communication plan that explains the objectives and rationale, the time frame and the cost of not changing. Implement the communication plan early and communicate often. Send out frequent progress updates. Focus the organization’s attention forward and generate an excitement about the new changes to the SDLC. Commission surveys or walk around the floor to learn if people understand the message. Are they getting it? Keep your communications credible, comprehensive and clear.

We’ve only touched upon a few aspects of organizational change management. There are a lot of moving parts to any organizational change, but especially so when rolling out a SDLC. An organizational change management strategy is much broader than the few examples I’ve presented here, but for a SDLC implementation, it is absolutely essential.

Taking AIM at Organizational Change Management – Part 1

I am a student of the AIM Methodology of organizational change management. AIM is an acronym for the Accelerated Implementation Methodology, a proprietary approach developed and perfected by Implementation Management Associates, Inc. (http://www.imaworldwide.com). Pfizer included me in a pilot AIM training program after their Learning and Organizational Development group decided to deploy the methodology to the Research and Development Division. I became a vocal advocate and champion of the process, even sending one of my direct reports to school to become an instructor

Don’t confuse this AIM with the other popular AIM, Oracle’s Application Implementation Methodology. Oracle’s AIM is essentially a legacy SDLC for the Oracle applications platform. The two AIMs couldn’t be more different. Also, don’t confuse organizational change management with project change management. Change management in a project context is very different from organizational change management. Project change management is a process by which changes to projects are formally introduced, vetted, approved, tabled or denied. An organizational change management method is not typically part of a SDLC or project management method although elements of organizational change management, such as communications plans, may be.

Organizational change management is about people’s behavior. Organizations are comprised of people and their behaviors formulate the accomplishments of the organization. Organizational change management explores behaviors to achieve greater results in performance which in turn drive bottom line value.

Just as IT system development methods share commonalities, so do change management methods. Regardless of the method you choose to follow, the core fundamentals of organizational change management are the same and must be observed if you want to achieve success.

Change management starts at the very top of the organizational structure. For IT, this starts with the CIO or CTO as he or she defines the strategic vision and goals. The CIO’s goals are aligned with the overall strategic goals of the organization as determined by the Board of Directors and the CEO with his/her senior staff. To successfully deploy an organizational change such as implementing a SDLC, it must be a strategic goal of the senior most leaders. As strategic goals cascade throughout the organization, it creates alignment with a clear and common language and understanding for the change.

Once goals are defined and distributed, assessing the organization’s readiness for change is the next step. How do you do that? Surveys are a good method. The goal of an organizational readiness survey is to uncover the barriers that exist within your organization’s climate, both current and historical. Barriers that may have impeded the progress of previous changes must be discussed to capture lessons learned. You’ll also want to uncover implementation strengths. What has gone right in the past that we can do again?

Identifying the approach you’ll take to implementing change follows the readiness assessment. You really only have two choices here. You can force your hand and generate compliance using the hammer approach or you can choose to build commitment and buy-in by managing the transition. On the surface, you may think the hammer approach is a little heavy handed and it may not be a good fit with your personal values. There are reasons where the hammer approach is the right approach. What if the change is due to regulatory, HR or safety compliance?

The second approach, transition management, requires more time to adapt a change. The organization becomes increasingly focused and the additional time allows for course correction along the way before implementation. You’ll gain greater buy-in, produce less waste and achieve greater precision in your implementations. Transition management is particularly effective when implementing changes in customer service, quality assurance and developmental paradigms such as the SDLC.

Organizational change will not happen efficiently without the right sponsorship. We’ve already talked about strategic goals cascading from the top down. Sponsorship is making certain the right people are doing the right things at the right times to demonstrate their commitment and ownership of the change. You’ll need an Executive Sponsor who has sufficient authority to authorize the change and commit the resources to make it happen. Then you’ll need Champions who can influence the organization’s commitments levels and Change Agents who’ll plan and execute the implementation.

Tomorrow, we’ll take a look deeper look at one of the most significant key success metrics of organizational change management: cultural fit. So stay tuned for Part 2.

Smart Executives Invest in IT During Economic Downturns

Whenever there is a downturn in the economy, two corporate groups that seem to bear the brunt of fiscal conservatism are Human Resources and Information Technology. Unless you are actually in the business of IT to generate revenue, in the corporate world, both of these departments are cost centers. Although they are both productivity enhancement enablers, it is often argued that they produce little to no direct bottom line value through their work.

In stark contrast to traditional business management theory, Dr. Howard Rubin[1] said in a presentation given at an October 2009 Gartner Symposium, “The most opportunistic time for technology investment is during an economic downturn; it is the only area in which investment can change the operating profile of an organization—doing so effectively can create an insurmountable competitive gap. Bad IT economics will put you on the wrong side of this gap and may even be creating advantage for your competitors.”

To gain competitive advantage during an economic downturn, smart executives invest in IT if they have the confidence in the IT organization to deliver that which is promised; quality products that meet or exceed customer expectations, on time delivery and well managed budgets. For IT organizations to be successful today and tomorrow, they must evolve into values-based cultures that drive high performance, low turnover, and increased productivity without impeding creativity and innovation. The organization must embrace defined, managed, measurable, repeatable and reusable practices that form the blueprint for their overall systems delivery strategy. The blueprint feeds the continuous improvement cycle. It’s said in the Six Sigma world, “If you can’t measure it, why are you doing it?”

This is where an effective SDLC helps. The SDLC provides a framework that describes the activities performed during each phase of a systems development project; activities that are defined, managed, measurable, repeatable and reusable, just what the doctor ordered. It endorses standards and practices to ensure consistency across projects and tasks undertaken by different groups within IT such as Telecom, Data Center, System Administration, Quality Assurance, Network, Applications Development and others.

Let me point out that I’m being very careful not to use the word “software” when discussing the SDLC. I use the term “system” to emphasize the SDLC’s broader impact across all of IT. Undoubtedly, a major focus of any SDLC is software, but when you think of all the projects that are undertaken in an IT organization, every project team has a responsibility to:

• Elicit and analyze requirements
• Develop systems specifications
• Define success metrics
• Produce clear, consistent and unambiguous artifacts
• Deliver products that comply with the highest quality standards that meet or exceed customer expectations
• Transfer knowledge to operational support and maintenance personnel, sometimes to outsourced, off-shore locations
• Train end users and support resources
• Offer post deployment support and maintenance

Are these statements true or false? If true, then consistent reusable processes and practices across the entire IT organization are critical for an organization’s absolute success.

---

[1] Gartner Senior Advisor, Founder Rubin Worldwide, MIT CISR Associate, howard.rubin@rubinworldwide.com

When Outsourcing, Multi-cultural Training Means the Difference between Success and Failure

In a May 2004 study entitled “Leading Causes of Outsourcing Failures,” the Outsourcing Center[1] surveyed 305 buyers and providers in North America, Europe, Asia and India to assess their experiences and opinions about outsourcing failures. One-third of respondents were buyers, two-thirds were providers. They concluded that 25% of the reasons for outsourced project failures are due to poor communication (16%) and cultural fit (9%). If you believed 25% of your outsourcing projects would fail because either you or your provider didn’t understand each other, even though you both speak the same language, or innocently offended each other because you didn’t understand each other’s cultural mores, you would do something about it wouldn’t you?

Multi-cultural or cross-cultural training is a key success factor when considering outsourcing. Gerard (Geert) Hendrik Hofstede is an influential Dutch sociologist whose life’s work includes the study of the interactions between national cultures and organizational cultures. Hofstede defines five dimensions of culture in his study of national work related values which are:

• Individualism vs. Collectivism: measure of how greatly members of the culture define themselves apart from their group memberships
• Long vs. Short Term Orientation: A society's “time horizon” or the importance attached to the future vs. the past and present
• Masculinity vs. Femininity: the value placed on traditionally male or female values
• Small vs. Large Power Distance (PDI Scale): A measure of how widely the less powerful members of society expect and accept that power is distributed unequally
• Weak vs. Strong Uncertainty Avoidance: A metric of how extensively members of a society are anxious about the unknown and try to cope with anxiety by minimizing uncertainty

Having an understanding of the Hofstede PDI scale provides insight into one of the foremost causes of cross-cultural communication failures—the difference between high context and low context communication. The low context communicator expects straightforward conversation. If there is a problem, s/he expects a straightforward answer with specifics. In high context countries, subordinates acknowledge the power of others based on their formal hierarchical positions. The subordinates offer their superiors great respect. Out of respect, the high context communicator doesn’t directly inform their superior of project issues due to the concern that the superior may suffer an offense. Neither person is doing anything wrong. They are merely observing the cultural norms of their respective countries.

Effective cross-cultural training solves the issues that resulted in the 2004 survey’s 25% of project failures. Preparing employees to work outside of their native country or to work with offshore outsourcers is extremely important for outsourced project success. Basic multi-cultural training includes:

• Action plan for living abroad
• Communication characteristics and role
• Doing business in the country
• Eating and drinking
• Education, studies and professional training
• Introduction to culture and history
• Laws, norms, taboos and values of the society
• Leisure activities and customs
• Social contacts, friends and acquaintances
• Relations at work and management
• Women’s life and role in society

Without understanding those cultural norms, communication breakdowns lead to project failures. One of the greatest mistakes any IT organization can make is to enter into an outsourcing agreement without first subjecting its key players to basic multi-cultural training.

 

---

[1] The Outsourcing Center is a wholly owned subsidiary of the Everest Partners, L.P.; Two Galleria Tower, 13455 Noel Road, Suite 2100; Dallas, TX 75240; PH: 214-451-3000 FAX: 214-451-3001; http://www.outsourcing-center.com/

Excellent Book Reviews So Far

Writing and publishing a book can be a long, drawn out process. One of the steps that must be performed before the book goes to press is the “peer” review. A little over a month ago, I sent the book out to five people to look it over and comment on the content. So far, we’ve had two of the five send the reviews back. Here’s what they said:

"This book is a great roadmap to anyone developing a System Development Life Cycle. It's contains a wealth of research, comparative analysis and valuable lessons learned from someone who's been there, done that. The information compiled here by the author will save you time and money. I especially liked the Handy Desk Reference loaded with useful charts and graphs" —David Nilsson, Architect Principal Leader, Computer Sciences Corporation

“The author has truly ‘hit the nail on the head.’ Whether you are an academic student who is aspiring to be an IT professional one day, a trainee that has just started career, a business & quality analyst and manager that has years of IT SDLC project experience—a must read for an IT professional at all levels of IT journey” —Sekhar Bommana PMP, ITIL, VP – Strategic Solutions & CoEs, Infomerica, Inc.

I’m anxious to learn what the others think as well. I’ll keep you posted.

The SDLC is Not Just for Software

There was a recent question posed on LinkedIn about what the acronym SDLC means when you see it in a job posting. The question was asked by a person identifying themselves as a job-seeking business analyst. I followed the thread with amusement as the many responses were posted, none of which answered the question adequately. Of course, I couldn’t resist putting in my two cents only to have someone snidely remark, “It’s good to hear from a self-proclaimed expert on the SDLC.” The commentator then went on to offer badly formed advice. It is very amusing!

The truth is the SDLC is not just about software. While software is a major focus of any SDLC, it is not the only focus.  That’s why I prefer to define the acronym SDLC as System or Solution Development Life Cycle and not Software Development Life Cycle. To do otherwise is a misnomer. Need proof?

Think about all the projects an IT organization takes on. It doesn’t matter if the project is in telecom, infrastructure, application development or even outside of IT as in opening and outfitting a Greenfield location. True or False? All of these projects have certain process commonalities that can be governed by an effective SDLC. Every project needs to:

1. Elicit and analyze requirements
2. Develop design specifications
3. Define success metrics
4. Produce clear, consistent and unambiguous artifacts
5. Deliver products that comply with the highest quality standards that meet or exceed customer expectations
6. Transfer knowledge to operational support and maintenance personnel, sometimes to outsourced, off-shore locations
7. Train end users and support resources
8. Offer post deployment support and maintenance

All of these development aspects are governed by a well-defined and effective SDLC. It doesn’t take a giant leap if faith to conclude that the SDLC is not just about software.

Contents of the Book

There has been so much interest in what is written in “Principles for Maturing Your System Development Life Cycle: The Ultimate Guide to the SDLC” that I’ve decided to publish this descriptive table of contents. I hope it satisfies your curiosity, but if you have any further questions, please feel free to send me an email.

•    Forward
•    Chapter 1—Introduction
     o Rationale and purpose of the SDLC
     o Organizational change management and its impact on the successful implementation and adoption of the SDLC
     o IT Governance and how the SDLC’s processes help decide IT Investment opportunities
     o Project Management method and its synergies with the SDLC
     o Compares the project management triangle (i.e., scope, time and cost) to my invention of the SDLC triangle (i.e., quality, consistency and product delivery)
     o Compares the five basic process groups of project management to the five basic process groups of the SDLC
     o Ties it all together by presenting my third invention, my theory on the three-legged stool of IT business value: IT Governance, Project Management and the SDLC
•    Chapter 2—System Development Models
     o Discussion of team empowerment
     o Historical look at the evolution of twelve traditional waterfall, agile and hybrid development models to examine shared commonalities and best practices
     o Waterfall, Modified Waterfall, the Spiral Model, V-Model and Dual V-Model
     o RAD, Scrum, Crystal, Extreme Programming and Dynamic System Development Model
     o Incremental Commitment Model and Lean Philosophy
     o Best practice comparison charts
•    Chapter 3—Requirements Maturity, IT Governance & Planning
     o Poor requirements and project failures
     o Importance of business analysis training
     o IT Governance
          Structure
          Work intake and the requirements process
     o Requirements Process
     o Importance of Requirements Maturity
     o Requirements Planning
•    Chapter 4—Requirements Elicitation
     o Requirements Elicitation Activities and Techniques
          Brainstorming
          Focus Group
          Interview
          Observation
          Prototyping
          Modeling standards: UML and BPMN; Emerging standard: SOMF
          Requirements Workshop
               Managing Scope Creep
          Survey
•    Chapter 5—Requirements Documentation & Quality
     o Requirements Documentation
     o Business Requirements Definition
     o Good Requirements Quality Checklist
•    Chapter 6—Requirements Analysis, Inspection & Tracing
     o Document Analysis
     o Interface Analysis
     o System Requirements Specification
     o Quality Assurance Inspection Stage Gate
     o Baselining Requirements Artifacts
     o Traceability Matrix
     o Requirements Phase Artifacts
•    Chapter 7—Design & Development
     o System Design Specification
     o System Analysis Methods:
     o Business Process Analysis & Design
     o Object-oriented Analysis & Design
     o Service-oriented Analysis & Design
     o Structured Analysis & Design
     o Data Modeling
     o Design Quality Review Stage Gate
     o Development Cycles
          Kick-off Meeting
          Daily Stand up
          Test-Driven or Test First Development
          The Development Cycle
     o Development & Coding Standards
•    Chapter 8—Pre-Implementation Activities & Artifacts
     o Implementation Plan
     o Detailed Test Plan
     o Training Artifacts
     o Operational Turnover Artifacts
     o Service Level Agreements
     o Change Request
     o Design & Development Phase Artifacts
•    Chapter 9—Quality Assurance & Implementation
     o Quality Assurance vs. Quality Control
     o Quality Models and Standards
     o Defect Classification
          Simple Classification System
          Orthogonal Defect Classification
     o The SDLC Test Battery
     o Verification Readiness Review
     o Release Management
     o Configuration Management
     o Subcontractor Management
     o Multi-Cultural Training
     o Implementation Readiness Review
     o Deployment
     o Operational Readiness Review
•    Chapter 10—Continuous Improvement
     o Embedding Continuous Improvement into and organization
     o Business Transformation Governance
     o W. Edwards Deming on Business Transformation
     o Capability Maturity Model Integration
     o Kaizen
     o Theory of Constraints
          Microsoft TOC Case Study
     o Kanban
          Corbis Kanban Case Study
     o Scrum-ban
     o Statistical Analysis Variants
          Six Sigma
          Lean Six Sigma
          Theory of Constraints Lean Six Sigma
     o IT Performance Measurement
     o SDLC Metrics
          Lifecycle Framework Metrics
               Cost of Quality
               Defects
               Effort
               Requirements
               Size Variance
          Value Chain Metrics
               Knowledge Transfer
               Quality of Service
               Steady State
          Quality Assurance Metrics
•    Chapter 11—Handy Desk Reference
     o The Principles
     o Twenty-four of the most important diagrams and tables
     o Good Requirements Quality Checklist

The Three-Legged Stool of IT Business Value

Once during a meeting I attended while visiting an affiliate organization in the San Francisco area, the CEO shared his vision of business success as a three-legged stool of margin, sales and net profit. If any of the three legs of this stool are out of balance, revenues suffer and shareholder value declines. In “Principles for Maturing Your System Development Life Cycle: The Ultimate Guide to the SDLC,” I present my own theory of a similar three-legged stool that applies to the business value IT provides to an organization. In my thesis, the three-legged stool of IT business value is comprised of IT Governance, the Program/Project Management Method and the SDLC. The three are inextricably linked and together form a trilogy that are foundational to IT success and the business value IT provides.

 
In the corporate world, a truly effective IT group can help increase revenues, develop and hold market share, gather mission-critical employees, view mission-critical processes and plan niche creation strategies. An ineffective IT Governance crushes an organization. It leaves senior leaders with a bad taste in their mouth. They lose confidence and trust in the IT group to deliver what they’ve promised. A poor project management method leads to project failures, cost overruns and delays. An immature SDLC results in poorer quality products, increased defects and lower customer satisfaction. All three must work in concert and all three must be effective to produce the desired results. Effectiveness is measurable and can be continuously improved. If any one component is out of balance, our projects may topple and fall; and like Humpty-Dumpty, we may not be able to put all the pieces back together again.

Book is Complete, Time to Reenter the Human Race

For the past 3 ½ months I’ve been writing a book called “Principles for Maturing Your System Development Life Cycle: The Ultimate Guide to the SDLC.” It’s a collection of best practices, activities and processes gathered from leading industrial nations and the minds of some of the greatest thought leaders in Information Technology in the latter half of the 20th and the 21st centuries. Its details incorporate a history and comparison of a dozen systems development methods and philosophies, from waterfall through agile, and many of today’s recognized best practices and standards all the way to continuous improvement and performance metrics. Its concepts, principles, practices, disciplines, guidelines and models are demonstrated to help deliver successful Information Technology projects and mature organizational practices from ability to capability.

Many authors say their books are a labor of love, but I’ll only admit to the labor part. Writing a book is an arduous task and one of the hardest projects I’ve ever undertaken. In all, I’ve invested over thirteen months bringing this project to fruition. This includes over ten months researching, reading and studying and about three and half months writing eight to ten hours a day, six days a week; all the while keeping up with family and parental responsibilities and service to the community. Believe me, it is labor! And it’s a labor undertaken with absolutely no assurance of financial reward. So why did I do it? I did it because there is a great need in the Information Technology world for this kind of book. I saw the need and had the availability, wherewithal, passion and drive to fulfill the need; and as far as I can tell, there isn’t anything else like it on the market. And even though it’s a labor, it is a labor well worth the effort and one that provides a deep satisfaction in knowing this is a job well done.

I’ve spoken to other authors who describe the experience as bringing a baby into the world. I’ll never know what it’s like to give birth and can’t compare the two, although I suspect writing a book is much easier. But now the book is done, the baby is born and I can wake up from my long hibernation to move forward on the job search. For the most part, I’m taking today off (okay, so I’m working about half the day). On Monday, I’ll emerge from my man-cave, stretch my legs and and reenter the human race.