1. Improving Project Success through Systems Development Methodologies
Patty Patria , Director, Enterprise Initiatives

2. Overview
Overview of Bentley culture and how it impacts technology projects
Discuss the drivers behind a formal SDLC process
Discuss the planning & design process
Review the SDLC components
Discuss benefits
Q&A

3. Bentley Facts
Bentley is a business school that focuses on the integration of business with information technology.
We enroll approximately 4,000 undergraduate, 1,250 graduate and have 2 PhD programs. We have almost 50,000 alumni and are located on 163 acres in Waltham Massachusetts, 10 miles west of Boston.
We have a centralized IT environment, but there are several departments within IT that work on most major initiatives.
Very high security levels, but short on formal standards for those levels.

4. What is an SDLC?
Systems Development Life Cycle (SDLC), or Software Development Life Cycle process of developing systems, and the models and methodologies, that people use to develop these systems, generally computer or information systems.
Source: Wikipedia
What does this really mean? Creating a process that facilitates information gathering, communication and signoff so that everyone is on the same page.

5. Bentley Structure

6. Problems without an SDLC
Complex IT Projects that require work by multiple departments
Lack of full requirements at front end
Communication breakdown and finger pointing if things go badly
Although it would be nice to have a cookie cutter system for technology projects, technology changes so rapidly, it is difficult to set standards, then keep those standards without revision.
An example of a project that went poorly, was a standard upgrade to our Advancement application. When rolled out 3 years ago, it was acceptable to have a front end web server in the DMZ because VPN was not as widely used or as accepted for general use. During a routine upgrade, we kept the server in the existing location. Once upgraded, the Director of Networks was upset because he did not think that server should be in our DMZ. After some quick scrambling after the upgrade, the server was moved. This is an example of technology changes that was not know, affecting an existing application. Similar problems arise on new implementations and new data integrations.

7. Major drivers for an SDLC
Problems with approvals within IT Departments
External IT audit found lack of formal procedures for new technology projects
COO mandate to create an SDLC process
Beyond the problems I just noted, we also an external IT audit performed.

8. How Bentley created our SDLC
Formed working team of 3
Researched best practices
Identified key players
Identified input
Identified output with signoffs
Reviewed 1st draft with COO
Formed a team of three; myself, our Director of Administrative Systems and our Manager of Database Administration. We researched other SDLC processes, consulted our PMs for templates they used at previous places of employment. We assessed key players and who should be involved at what stage and where people should sign off. We created a first draft and reviewed with our COO.

9. Our first draft

10. Our second draft

11. Components of SDLC Request Phase Analysis Phase Design Phase
Build Phase
Documentation Phase
QA/Testing
Implementation
Maintenance
Although it might seem like a lot, there are all normal phases of projects. We just added process and signoffs at most of those phases.

12. Request Phase Electronic request from Key User VP sign off via e-mail
Dir. of A.S. sign off via
Dir. of E.I. sign off via
If a small project or something that leverages existing technology, the Key Users fills out the request form, their VP signs off on the request, and then our Director of A.S. and I jointly review and approve. If we need to make modifications, (i.e. Next week is unrealistic for this, we do that and send it back to the Key User.
If this is a major project, we engage in an RFP, review architecture of selected vendor, request funding (and get funding), then move to the next phase.

13. Analysis Phase
Detailed functional specifications which include any systems and network components
Formal review meeting by Key Users and all key IT personnel
Sign off by technical team, Director of SNT, Data Security Administrator and VP
This is the core of the new process. There is a significant amount of effort performed in this phase to document why we need the solution, the ROI, how the technology will work, network diagrams, etc.

14. Design Phase Project Kickoff with Project Plan
Technical Review & Code Walk through
Signoffs by Manager of Database Administration, Developer, Key Users, Project Manager and the Director of A.S.

15. Build Phase Develop application or implement product
Create necessary interfaces
Perform developer testing, functional testing and data integration testing
This used to be thought of as the meat of the project; by this point now we have performed significant analysis and upfront work to make sure anything new we build is correct or any new products we implement (hosted or non hosted) are in accordance with the University’s Security standards. Although I am not the person doing the building, I now consider this the easy piece!

16. Documentation Phase
Create uniform test plans, project plans and custom training material
Ensure documentation is up to date.
This is one phase that does not have a formal document. However, we do use standardized test plans, and create FAQs, and training materials as needed on projects. Sample of a test plan is attached, but do to the nature of IT projects, and the changes that occur, we give project managers more flexibility to customize the test, project plans and documentation.

17. QA/Testing Phase Perform IT testing & Client Testing.
QA Test Plan signed at multiple levels.

18. Implementation Phase
Communication Plan, Production Task List and SLA are major deliverables
Also make sure we test for Disaster Recovery if necessary

19. Maintenance Communicate changes in ownership if necessary Address bugs
Hold post-mortem on project to discuss what worked, what did not and how to improve
Any questions on things so far? Have I scared everyone with too much detail?

20. Detail and Governance Create documentation to back up your flow
Create a tool to track all projects
Although the visual, color coded flow chart is great as a quick reference guide, it is good to have more detailed backup of what should happen in each stage, and the signoffs if people forgot and need to reference the details.
It is also helpful to have one master spreadsheet that shows where you are in all projects to make sure deliverables are getting addressed.

21. Process Time Line Began in May 2008
Approved process in August 2008
Revised in October 2008
Revised again in January 2009 due to re-org

22. Benefits Better communication = more project success
VPs are more aware of technology projects
Key players now approve and signoff before purchase or implementation
Fewer problems post implementation
Better communication = more project success

23. Changes Over Time Electronic approvals via e-mail
Hand written signatures
VP approval via
VP Meeting at Functional Analysis stage
Integrated into Functional Analysis
Separate Network & Security Review

24. Lessons Learned Process will need several rounds of refinement
Make sure signors understand what their area of responsibility is (i.e. network security or all security)
You may experience resistance at first…
Investing time on the front end, saves problems on the back end.

25. Additional Information
Forms and Life Cycle Flow chart can be found at
Other questions can be ed to