Systemic Methodology to Project Management
We use a modified version of W. Edwards Demming's Plan Do Check Act Methodology. As Agile indicates, you cannot work in a vacuum. We pride ourselves on checking in regularly with our clients and making sure we are on track at every stage of the project. Because of this, we can maintain a No Surprises feedback loop to both management and our business customers.
Our typical projects are governed around the principles below.
Find the problem
If there is a problem that needs to be identified, we can find it and write up a Problem Statement for you.
With or without a Problem Statement in hand, we can query your business customers or management and determine a list of Requirements that everyone agrees with.
These requirements are best documented so that we can refer to them later. Especially in the Test Process. We test to our requirements document, so we want the Requirements Document to match Customer Expectations.
Testing is always in the crunch cycle. If Development needs more time, then it starts off at the expense of Testing. We offset this by addressing Test Scenarios and Test Requirements up front and determine ownership for all associated tasks. Who will create the initial data set? How about the delta data set? Who creates data in the Development environment versus the Test environment?
Let us get these questions answered up front. This way, people can plan vacations around an anticipated block of test time.
Developers need to stay on track and Customers need to know that Developers understand their requirements. A quick and easy way to do that is to create a prototype and show what the Developers are thinking. This gives instant feedback to both parties and reassures both that they are on the right track.
With a strong Requirements Document, Test Strategy, and Prototype in hand, Development comes down to resolving the difficult requirements. This is typically handled methodically by the team and after careful observation and rolling up of the sleeves, you will have a good idea of how long implementation will be for those difficult items. The easy items can also take time if the quantity is large. However, understanding the difficult tasks is paramount to completing your project on time and on budget.
There are four types of testing: Unit/Functional, System Test and User Acceptance Test, and Regression Test. All are important to creating an accurate reporting system.
Unit Test/Functional is involved in the Development process and occurs in the development environment. When a developer modifies some code or changes something in the system, the first test cycle is a Unit Test. The developer tests to make sure his changes have either positively impacted the data model or have provided the correct solution to his problem.
System Test is when you complete the testing of a wider set of parameters. This involves all Requirements listed in the Requirements Document and is generally conducted in the development (piecemeal by the developer) and quality/test systems. If tested in the quality environment, then a business/end user may create the data in the transactional system and the developer will show the data is correct on the reporting side or datawarehouse.
User Acceptance Testing is where the business customer gets the final say as to whether the requirements are met. If they customer has seen the solution several times, this typically goes smoothly. If this is the first time they have seen the solution, then get ready for a long night!
Regression Testing is where we re-test functionality that has already been running in production. This is to ensure new development has not broken anything that already exists and has been tested.
Sometimes Production Cutover is quick and easy. Other times, it requires a project plan of it's own. In either case, our experts have worked on multiple small and large cutover processes and are experienced. What is a smooth cutover? It is a cutover where everyone knows their roles and responsibilities and is available at the appropriate time when their steps are ready. We do this by simulating times for objects to move into the production environment and making sure corresponding developers are available during a windowed time frame around those times. If jobs happen faster than normal, then folks are updated immediately so they can be available. Once in production, developers check to see if code has moved in correctly and business users can check to see if new functionality is available. Once everyone is okay, the system is released for general use.
Once in production, the majority of the work is over. We do need to maintain some sustaining support for the project in the form of Hyper Care. This is where folks are on call just in case there was something missing in the Test or Requirements phase. Likewise, new data in a production environment could cause issues with some coding. Therefore, some level of Hyper Care support should be around for the first month after going live.