Are you challenged with a software development project that affects multiple areas of your organization? Does the project involve integration to multiple systems? Are you having trouble setting up priorities and allocating resources?
If this is the case, you may need to learn about Enterprise Project Management often referred to as EPM.
EPM assumes that not all software development projects are created equal. Depending on the size and structure of an organization, some software projects affect multiple departments in an organization; which can mean multiple sets of requirements and multiple expertise areas. Often times these projects include integrations to one or multiple existing software systems which have to be developed and tested before Go-Live.These kinds of projects are a logistical challenge since the Go-Live is essentially a restart of company operations.
Although multiple EPM tools are available, implementation can be a challenge. Bayshore Solutions uses a process that breaks down the project in multiple stages and serves as a guideline to managing Enterprise Projects effectively. Below is an outline of the areas of concern we have identified with EPM and how we manage them.
- If multiple areas of the company are affected by the project, break down the requirements per area and identify stakeholders to provide those requirements. This helps to keep the project moving in parallel and also helps keep the stakeholders invested in the project.
- After the requirements are compiled, look for duplicated requirements, then assign responsible parties to test common functional features.
- Subject matter experts (builders) need to exchange knowledge with stakeholders in order to develop a better understanding of the project. This involves project management, graphic design, SEO, Software Engineering and QA.
- Compile requirements in a single Enhancement Definition Document which will be used by software engineers to build the project. Although different areas have different requirements, software engineering needs to have access to a full set of requirements in order to design the system accordingly.
- Obtain sign-off from stakeholders in order to lock down requirements, if requirements change after the sign-off, create change orders and have them approved by management informing how this affects cost, go-live date and associated risks.
- Once the requirements have been identified, use subject matter experts (Graphic Design, SEO, and Software Engineering) to break down the project into multiple logical stages. A stage should produce a deliverable which can be tested and approved.
- Identify the correct build sequence for the stages according to functional logic.
- Rather than developing a long and complex project plan, develop a project plan per stage. Each stage should be a deliverable that can be tested, presented to the users and approved after a reasonable amount of testing.
- Release completed pieces to a staging location so testing is continuous and the team can see how the project is building up.
- Identify stages that can be built in parallel and work them accordingly.
- Approved deliverables should be locked down as much as possible.
- Once the Enhancement or Scope Definition Document has been signed and approved by the stakeholders, the UI (front-end) can be designed by UI team and approved by users.
- The Enhancement or Scope Definition Document should use wireframes and graphs.
- Software Engineering should select a development framework that fits the project requirements. It is important to keep in mind the amount of content, data requirements, data complexity, external feeds, graphics and integration to third party systems.
- The back end of the system can be designed. This design is basically a mapping of the requirements compiled and needs to be able to support the future enhancements.
- Frequent communication among parties is key to keeping the project moving and on track.
- Building the system is usually the part of the project that takes the longest to accomplish. It is important is to keep an eye on the build sequence of the stages. If any issues or errors are detected, the project plan and release schedule must be modified accordingly and stakeholders notified.
- Use the appropriate source control mechanisms to archive versions of the project as needed and properly document change sets.
- Identify plan deviations and modify the project plan and release schedule accordingly.
- Notify the appropriate parties when a stage is ready for testing and allocate time for modifications and/or defect fixing.
- Try to lock down functional processes when they are completed as much as possible. Use automated testing to ensure that these functional pieces are operational and unaffected by new functionality.
- Test each stage independently if possible, and then test each stage in conjunction with other functional pieces. This helps to narrow issues to a particular area or as an integration element.
- Have a stage environment dedicated for testing. Never test on development environments since they are subject to change
- Once a stage has been tested, release it by obtaining confirmation from stakeholders.
- Develop a plan to test third party integration and make sure that data flows across systems by using flowcharts to diagram functionality. Obtain clarification and confirmation from stakeholders.