Projects and Planning
Projects are one of the primary ways ISS creates, replaces, upgrades, or significantly changes technology services.
Within the ISS Plan → Build → Operate operating model, projects most often represent structured Build work. Planning for a project may begin in Plan, and the completed project ultimately transitions its results into Operate.
ISS uses a defined project methodology to help teams organize this work, reduce risk, coordinate people, communicate effectively, and deliver results that provide value to the College.
The methodology is a guide, not a rigid checklist.
The amount of project-management structure required should be appropriate to the size, cost, complexity, risk, and impact of the project.
Plan Before You Build
ISS deliberately places significant effort into preparation before execution.
Good planning helps us:
- Understand what problem we are trying to solve.
- Understand who will be affected.
- Define what success looks like.
- Identify requirements before selecting or configuring solutions.
- Coordinate people and resources.
- Identify risks and dependencies.
- Prepare communications.
- Plan testing before deployment.
- Reduce rework and unexpected disruption.
The principle is simple: prepare the axe before trying to chop down the tree.
Planning takes time, but inadequate planning often costs far more time later.
A Scalable Methodology
Not every project requires the same level of formality.
The manager and CITO determine the appropriate level of project-management rigor based on the needs of the project and the College.
Factors may include:
- Project cost
- Number of people affected
- Number of departments involved
- Complexity
- Risk
- Service criticality
- Security implications
- Amount of organizational change
- Vendor involvement
- Required coordination
- Visibility to College leadership
- Effect on students, faculty, and employees
A project involving millions of dollars, multiple departments, and nearly every member of the College community requires significantly more planning, communication, coordination, testing, and documentation than a small internal technology project.
ISS scales the methodology accordingly.
Formal Project Process
Larger or higher-impact projects use the formal ISS project process.
ISS project templates help managers and project teams create the artifacts necessary to support the methodology.
The templates provide structure for activities such as:
- Project charter development
- Requirements
- Communication planning
- Testing
- Solution evaluation
- Procurement
- Deployment planning
- Documentation
- Training
- Traceability
- Go-live preparation
- Lessons learned
- Transition to maintenance and operations
The templates exist to help teams manage the work. They should not become paperwork created only to satisfy a process.
Project artifacts should be useful to the people planning, performing, reviewing, supporting, and ultimately operating the resulting service.
Minimum Project Plan
Smaller projects may use a much simpler planning approach.
The plan may be contained in an email, Word document, ticket, or another appropriate project artifact.
Regardless of project size, every project must have a plan containing at least five elements:
- Purpose
- Names of the project team members
- A list of milestones
- Milestone due dates
- Milestone owners
These five elements represent the minimum project discipline expected in ISS.
If we cannot clearly identify why the project exists, who is involved, what must be accomplished, when it should be accomplished, and who owns each milestone, we do not yet have an adequate project plan.
The ISS Project Mantra
Regardless of project size or documentation method, the project-management philosophy is summarized in four steps:
1. Make a Plan
Understand the purpose of the project and determine how the work will be accomplished.
Identify the people, milestones, responsibilities, dates, dependencies, communications, and other information appropriate to the size and complexity of the project.
2. Vet Your Plan
Plans should be reviewed before significant work begins.
The level of review should match the project.
Depending on the work, vetting may involve:
- The project team
- The responsible manager
- The CITO
- Service Owners
- Technical Leads
- Customers
- College stakeholders
- College leadership
- Vendors
- Other departments
Vetting gives the people affected by the work an opportunity to identify missing requirements, risks, assumptions, dependencies, timing concerns, or other issues before they become expensive problems.
3. Work Your Plan
The project plan is a working document, not something created at the beginning and forgotten.
Teams should use the plan to guide the work, track progress, coordinate responsibilities, and communicate status.
Plans may change.
New information may require:
- Different milestones
- New due dates
- Changed responsibilities
- Additional requirements
- Revised technical approaches
- Different deployment timing
Changing a plan is not a failure.
The important expectation is that significant changes are deliberate, documented, communicated, and reflected in the working plan.
4. Finish Your Plan
A project is not complete simply because the technology has been installed or turned on.
Finishing the plan means completing the work necessary to successfully transition the result into normal College operations.
Depending on the project, this may include:
- Completing testing
- Completing documentation
- Providing training
- Communicating deployment
- Completing the go-live process
- Resolving outstanding issues
- Transitioning responsibilities to operations
- Establishing maintenance
- Completing lessons learned
- Closing remaining milestones
The goal is not merely to deploy technology.
The goal is to deliver something the College can successfully use, support, maintain, and improve.
ISS Project Methodology
For formal projects, ISS uses a five-phase methodology:
Plan → Design → Build → Test → Deploy
The methodology provides a common framework for understanding project progress and the work expected during each phase.
The percentages assigned to the phases and activities represent the ISS project-completion model.
Plan — 10%
The Plan phase establishes why the project exists, what must be accomplished, who is affected, and how the project will be approached.
Project Charter — 2%
The project charter establishes the project at a high level.
Depending on the project, it may describe:
- Purpose
- Business need
- Scope
- Project team
- Stakeholders
- Goals
- Major assumptions
- Constraints
- Responsibilities
Requirements — 5%
Requirements define what the project must accomplish.
Requirements should focus on the College need before the team becomes committed to a particular technical solution.
Good requirements help guide:
- Solution evaluation
- Configuration
- Testing
- Traceability
- Acceptance
Communications — 2%
Projects should identify appropriate communication needs early.
Communication planning may consider:
- Who is affected
- Who needs project updates
- What people need to know
- When communication should occur
- Who is responsible for communicating
- What communication channels should be used
The amount of communication required should reflect the scope and impact of the project.
Test Planning — 1%
Testing should be considered before the system is built or configured.
Early test planning helps establish how the team will determine whether requirements have actually been satisfied.
Design — 25%
The Design phase determines how the identified requirements will be satisfied and prepares the project for implementation.
Solution Evaluation — 13%
Potential solutions should be evaluated against the project's requirements and College needs.
Evaluation may include:
- Functionality
- Architecture
- Security
- Accessibility
- Integration
- Supportability
- Reliability
- Cost
- Vendor capabilities
- Licensing
- Long-term sustainability
The goal is not simply to select technology.
The goal is to select an appropriate solution to the identified College need.
Procurement — 8%
When purchasing is required, procurement activities are part of project planning and delivery.
These activities may include:
- Quotes
- Contracts
- Purchasing requirements
- Budget approval
- Vendor coordination
- Licensing
- Required College reviews
Procurement should be considered early enough that purchasing requirements do not unexpectedly delay the project.
Deployment Planning — 2%
The team should determine how the solution will move from implementation into production.
Planning may include:
- Deployment timing
- Dependencies
- Maintenance windows
- Customer impact
- Technical sequencing
- Support preparation
- Rollback or recovery considerations
Go-Live Checklist — 2%
A project should identify what must be true before the team considers the solution ready for production.
The Go-Live Checklist provides a deliberate readiness check rather than allowing deployment to occur simply because configuration appears complete.
Build — 40%
The Build phase is where the solution is created, configured, integrated, or otherwise prepared for use.
Configuration — 20%
The project team performs the technical work required to implement the approved design.
This may include:
- Configuration
- Development
- Integration
- Installation
- Migration
- Automation
- Technical implementation
Traceability — 5%
The team should maintain a connection between project requirements and the solution being created.
Traceability helps answer:
Where and how was this requirement addressed?
This helps prevent requirements from disappearing during implementation and creates a foundation for later verification during testing.
Documentation — 10%
Documentation is part of the project, not something deferred until after deployment.
Appropriate documentation may include:
- System configuration
- Architecture
- Support procedures
- Administrative procedures
- Customer documentation
- Troubleshooting information
- Dependencies
- Vendor information
- Operational responsibilities
A system that works but cannot be effectively supported or maintained is not fully implemented.
Training Plan — 5%
The team should determine who needs training and how that training will occur.
Training may be required for:
- Customers
- Help Desk staff
- Technical staff
- Administrators
- Managers
- Other College employees
Training should be planned while the solution is being built rather than discovered as a need immediately before deployment.
Test — 10%
The Test phase verifies that the solution is ready for production and satisfies the requirements established during planning.
Comprehensive Testing — 6%
Testing should be appropriate to the solution and its risk.
Testing may include:
- Functional testing
- Integration testing
- Security testing
- User testing
- Performance testing
- Failure scenarios
- Support procedures
- Deployment procedures
Verify Traceability — 2%
The team verifies that project requirements have been addressed and appropriately tested.
This closes the loop between:
Requirement → Solution → Test → Result
Test Closure — 2%
Testing should have a deliberate conclusion.
The project team should understand:
- What was tested
- What passed
- What did not pass
- What outstanding issues remain
- Whether identified risks are acceptable
- Whether the project is ready to proceed toward deployment
Deploy — 15%
The Deploy phase transitions the completed project into production and normal operations.
Go Live — 5%
The approved solution is placed into production according to the deployment plan.
The team should monitor the deployment and respond appropriately to unexpected conditions.
Training — 6%
Planned training is delivered to the appropriate audiences.
The people responsible for using and supporting the service should have the information necessary to succeed.
Lessons Learned — 2%
The project team should consider what was learned during the project.
Questions may include:
- What worked well?
- What caused difficulty?
- What should we do differently next time?
- What surprised us?
- What should become a standard practice?
- What should be avoided in future projects?
Lessons learned are intended to improve future work, not assign blame.
Maintenance — 2%
The project must transition into an appropriate operational and maintenance state.
Before closing the project, ISS should understand:
- Who owns the resulting service or service offering.
- Who serves as Technical Lead and Backup.
- What recurring maintenance is required.
- How the Help Desk will support the service.
- Where documentation is maintained.
- What vendor or licensing responsibilities remain.
- What monitoring is required.
- What lifecycle considerations should be planned.
This transition moves the result of the project from Build into Operate.
Projects and Our College Values
ISS projects should reflect the values of McLennan Community College.
People Matter.
We consider the people affected by our projects and how changes will affect the way they learn, teach, work, and interact with College services.
Inclusiveness Matters.
We seek appropriate perspectives and consider how project decisions affect different groups throughout the College.
Communication Matters.
We communicate clearly and without bias about what we are doing, why we are doing it, and when changes will occur.
Integrity Matters.
We tell people what we are going to do. We do what we said we would do. We tell people what we did. When circumstances require the plan to change, we update the plan and communicate the change.
Excellence Matters.
We strive to deliver projects that work, provide value, can be supported, and help McLennan Community College achieve its mission.
The methodology helps us put those values into practice.