Chapter 12: Putting It All Together

---

At the beginning of this book, in Chapter 1, I mentioned the absolute need for an SPMO to embrace a methodology and to use it for all software projects an IT organization will undertake. The next eight chapters described each phase of the SEP methodology in terms of how a business leader would expect the project to flow. Each chapter has provided a solid, evolutionary progression of the project development effort from a management viewpoint. The overview of each phase of the methodology is important because it sets standards and expectations for you, the IT leader. When you are looking at taking on any new effort, you want to ensure that you have the best set of tools, practices, procedures, and so on available to help you succeed. Understanding the SEP process is a key gating factor to your success. Granted, you may personally believe in another methodology and be more comfortable with it, but it really does not matter which methodology is used as long as it achieves the desired level of results and has been defined and documented with an equivalent level of detail as what has been provided in this book.

SEP was chosen because it is the most widely recognized software development project model used in the business world today. There are newer models out there, but the truth of the matter is that most IT leaders choose to go with an industry-proven model that will not limit their ability to succeed. When your reputation and your job are on the line for a project deliverable, it is not worth taking chances by using a model that is not widely known or proven across the software industry and over the course of years of use. Remember, you are reaping the benefits of the evolution of this methodology over those many years of trial by fire in the trenches of businesses worldwide.

12.1 Beyond SEP Methodology: Making It All Work

It is my strong belief that one of the greatest strengths an SPMO adds to an organization is process standardization. Part of this process standardization includes having the organization align its activities to a standard method of getting work done (e.g., SEP) and by using the same activities defined in a process for each phase of each project the SPMO has under management. Additionally, enterprise project document standardization is achieved as a side effect of the combination of process and methodology standardization.

When every project is using the same approach to get work done, people-begin to align their thoughts, expectations, vocabularies, and efforts toward the goal; they begin to function as a team. This team effect strengthens the overall expectation of project success, and I believe it allows people the opportunity to fully commit themselves to their work. It is my experience that once expectations are known and work assignments are understood, people generally tend to step up and get the job done far beyond my expectations.

The net effect of this process standardization is a common understandingof what is expected when a project request is submitted. The project initiation request sets expectations for a series of known activities and events to take place. In effect, it raises the bar of expectations in an organization because the new minimum standard is to do better than the last project. With the SPMO processes in place, all of the resources, documents, histories, work products, and so on of the previous project ( including the things that went wrong) are available to the new core team as it begins to take on a new project. It is part of the SPMO team’s responsibility to ensure this ideal is upheld and adhered to for each new project that is started.

---