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

Opportunities and Redemption Abound on the Internet

Ever since my position was eliminated in December 2009 due to the recession, more doors of opportunity have opened for me than I ever imagined. First there was the public speaking engagement at AITP, then invitations to meet new friends for coffee or breakfast that may not have happened otherwise, frequent opportunities to discuss my book with people; and finally, becoming a registered facilitator of the Lead Like Jesus Encounter Workshop. All of this because of the Internet. (Then there’s also the Executive Consortium in which I have a leadership role, but more on that in a future post.)

This week I was introduced to a yet another new opportunity and even made a new friend because of it. Ken Whatmore from Colorado is my new friend. I’ve never met Ken in person to shake his hand, nor do I know if we’ll ever be in the same place together at the same time to actually meet in person. We have spoken on the phone and corresponded with each other, yet I know Ken will be a life long friend. Why? Because He’s a true brother in Christ!

This past Tuesday, Ken posted this challenge in the Christian Professionals Worldwide group on LinkedIn: “Share your story - How you came to know Christ and how He has changed your life. Make a difference in a life by sharing! We'll record a show that airs Sundays at 7pm MTN on http://www.radio323.com.”

I responded to Ken’s inquiry with a brief synopsis of how I came to know Christ as my personal Savior in May of 1976. I got saved under the most unusual circumstances in which God spoke very directly and personally to me from the Scriptures. I learned of my hopeless condition as a fallen human being and unregenerate sinner; and Jesus saved me. While my testimony is too long to share here, the full story is on our family website at: http://www.fontlife.com/victor/testimony.aspx .

As the Director of Radio323, Ken asked if I would share my testimony with his listening audience. We recorded the show Wednesday morning. I spoke for about 30 minutes. The show, called “Redemption,” airs Sunday evening on the internet to a global audience. I’m sure you’ve heard of Doctors Without Borders, well Ken’s vision for his radio platform defines the term Ministry Without Borders.

Ken says, “I am developing what God really put on my heart—a community outreach ministry. A new kind of outreach though developing networks of business groups, student groups, community groups on one side of the coin and on the other, networks of Christian ministry and outreach organizations who need volunteers.” He adds, “this new show 'Redemption' is really getting at the heart of the radio ministry…”

Ken has been Director of the radio station since January of 2010 after leaving a long career in the automotive industry. Radio323 frequently broadcasts messages from Christian Professional Athletes and Celebrities. I am grateful that he has included me among this list of distinguished guests. For more information or to lend support to this vital endeavor, please visit http://www.radio323.com. And don’t forget to listen to my appearance on Redemption this Sunday night at 7pm Mountain and 9pm Eastern.