Project Methodologies
At the start of the project a decision was made to fuse two different project approaches to adapt to the needs of the User Guardian development. The rationale for this was to spend more time designing and working out the more difficult aspects of the project at the beginning of the development, which favoured a Waterfall approach. Then once the initial concepts had been proven to work the Agile approach would help accelerate the online implementation with a focus away from set design to mock-up and Agile user stories.
This was an interesting exercise to carry out as it seemed sensible that project management methods could be proven to be interchangeable during a development if planned in advance. This idea was based on a paper written in the second year of the degree foundation course comparing Agile and Waterfall development methods found in Section 1.4.
Successes of the Project Management Approach
One the major successes of the Waterfall approach was the ability to clarify the idea which made the Proof of Concept much easier to implement in Section 5.2. The scope reduction at the start of the design phase as a result of the risk assessment finding in Section 3.6 and the feature comparison in section 3.3 prevented possible scope creep for the development.
The clarification process of the design also discovered a large design flaw for creating the pre-determined Segregation of Duties rules. These rules could not be created until any actual user data was imported into the system, however the main strength and concept of the system was the ability to pre-set rules best on all possible combinations of access. This method allows for the detection of access breaches into the future if/when the rules or new applications are altered or added over time.
The discovery of the problem and solution is discussed in more detail in the progress blog in Section 9 - Entry 16th - 22nd Sept.
By finding the issue early a re-design was implemented and delays when this issue would have been discovered in the database PoC were avoided.
The Waterfall planning in the form of the task list in Section 1.5 worked well at the outset of the project in terms of structuring the research and building up the prerequisite software and hardware for the development, unfortunately this could not be sustained.
The delays in the Waterfall phase of the project caused a knock on effect for the Agile phase of the development. One positive of the Agile approach was that the first sprint could still be planned and completed before hitting the project deadline. This was achieved by using a smaller iteration/mini user story to ensure the navigation worked and one page operated in PHP as designed. The revised planning for sprint 1 is demonstrated in section 5.3.
Challenges of the Project Management Approach
The Waterfall approach was effective up until the research phases shown in red on the project task list in Section 1.5. The major issue was staying disciplined to the task deadlines and tasks when they were becoming overdue, and failure in not revising the tasks or deadlines in the project plan to allow for this.
This put the whole development behind to the point where the Agile part of the development could not be caught up with the original plan of performing two sprints. This is shown on the Gantt chart between July to early September in section 1.6.
The possible reasons for the project management failures could be two fold:
The lack of a customer or sponsor for the project meant that continual feedback and project exception management was not undertaken when the deadlines were missed. The lessons learnt in Section 6.4 discusses in more detail how this situation could be managed for the future.
The planning of the task was done without real estimation methods used from the outset. The estimations improved in the Agile sprint section in section 5.3 with granular task breakdown and difficulty points scoring undertaken. However the timescales even working full-time for a week during sprint 1 were still optimistic given the authors lack of coding experience.
As discussed in the successes, the planning of the first sprint however did go on to produce a very basic mocked up version, with limited functionality when the project plan was revised at this point. There was a fear that an online version of any description would have failed to appear.
Progress against the Project Plan
The project plan was on track until the 4th April. Days off and extra evenings were dedicated to the project to try and stay on track with the task list, however it was not possible to keep up. This was first realised in the progress blog on the weekend of the 15th and 16th of June (08. 15th and 16th June).
Too much time up until this point was devoted to the configuration of the hardware and the testing and building of different software environments as detailed in section 5.1 in the technology evaluation. This was a distracting factor and in hindsight paying for a hosted solution may have been more productive.
The research and investigation part of the project took much longer than expected. The research in this area was providing good professional insights that were useful in understanding an IAM tool that was being configured at the same time within the organisation that the author contracted for. More time than required was taken for professional interest at the expense of the project deadlines.
Towards the end of the project, time off from full-time work was taken to rescue the project with a weeks commitment to the design in August during a canal boating holiday (12. 16th - 22nd Sept) and an Agile sprint planned for a week between the 25th and 1st of December (13. Software development week).
The time off did result in a working prototype of the User Guardian tool, however the online development could have been much more successful if better managed back in June when the project started to slip. Recommendations to improve the project management aspects of the project can be found in the lessons learnt section 6.4.