Our success in consistently delivering quality projects and exceeding customer expectations is due in large part to our project delivery methodology that positions us at CMMI Level 3 (for more information about CMMI levels, please refer back to the CMMI section), to our skilled Team and to our PMP certified Project Managers.

We have leveraged PMI’s PMBoK, MSF and CMMI to build our own team skills and our methodology that provides all project team members and stakeholders with a clear step by step guide to follow all through the lifetime of the project.

The customized use of a proven process improvement methodology that is targeted for software projects (MSF for CMMI) combined with general best practices from the industry leading project management organization (PMI through it’s PMBoK) serves our end in having a repeatable, predictable, proactive, organization-wide methodology that enhances our overall projects’ quality and probability of success.

Each project that we do is split into a minimum of 9 serial Iterations and 8 overlapping Tracks (2 of which are continuous) which allows us to deliver faster while both being proactive and adaptive to change.

Each iteration may vary in duration but its main goal is to always deliver a pre-planned additional value over its predecessor while increasing the project stakeholders’ knowledge of the product being developed. A retrospective meeting is also held at the end of each iteration to document any important lessons learned and take them into consideration during the iterations to come.

The number of Iterations in the 4xx series (check picture above) is adaptable to the project itself and may therefore be reduced to 1 iteration or expanded to 3 or more depending on the project needs. The exact number and duration of Iterations needed for a project are estimated, planned and fixed in Iteration 1 based on the project schedule constraints, high-level requirements gathered and the identified risks.

The product vision as well as the high-level requirements, project plan and solution architecture are created and signed-off during Iterations 0, 1 and 2. Actual development/implementation starts with Iteration 3.

Detailed requirements gathering, planning and solution architecture definition for an Iteration is deferred to, and freezed, at the very start of the Iteration itself. This leaves room to change (controlled change) as the stakeholders’ knowledge of the product being developed increases over time. It’s also much more pragmatic than the illusionist old concept of being able to go for detailed planning at the very first stages of a project where ideas are still on paper.

Since delivering quality is among our primary concerns, the Stabilizing Track starts early in the process, with the 4xx Iteration series, where fixing bugs and making the necessary changes on the solution is relatively easier than waiting till the whole development is done to start doing it.

All detailed product requirements would have been gathered by the end of Iteration 4xx series. No left-over requirements that haven’t been tackled are expected after this stage of the process.

Development/implementation is completed by the end of Iteration 5 and it’s also during this Iteration that deployment planning is conducted. By deployment we do not only mean installation of the solution on the production environment but also documentation, training, product packaging and rollout.

As many Release Candidates as needed are tested and presented to the stakeholders during Iteration 6 until one of them gets approved and signed-off.

The Deployment Plan created in Iteration 5 is implemented and completed during Iterations 6 and 7.

Once the deployment is complete, the project is ready to go through its last Iteration, Iteration 8, during which the project sign-off is obtained from the customer and the project retrospective meeting and archiving are conducted internally. It’s also during this Iteration that the project is internally handed-over to the Netways Support Team who will be receiving and processing customer support tickets in case a Service Level Agreement (SLA) has been signed.

All through the lifetime of the project, 2 tracks are continuously running, the Governance Track and the Operational Management Track, and this is where Risk and Issue Management, Change Management, PMO and Team regular Meetings, Quality Assurance and some other important activities, that are rather project-level than Iteration-dependant, take place.

The different roles that need to exist in each successful project are depicted below. Each Project Team Member may play one or more of the below roles. A matrix showing which roles may be combined and which can’t is available to assist Project Managers while building the project team.>

Now that our methodology has been briefly explained, the below picture provides you with an idea of how this methodology actually maps and doesn’t contradict with the overlapping Process Groups defined by PMI.