Project Management within the Webteam
A run-through of the frameworks we have adapted and use and why
In 2017 we had a turning point with the change in the workforce and structure of the team. This was a perfect opportunity to recalibrate how the Web Development team operated to ensure we were running at an optimum capacity, providing the greatest service and maintain high levels of code and security. As the whole team process’s and structure has been reviewed the way in which projects operate came under scrutiny to better formalise the approach. And so the following explanation explores two frameworks we have adapted, PRINCE2 and DSDM, and why we felt these methods would help us achieve our goals.
The PRINCE2 approach to Project Management
PRojects IN Controlled Environments.
The IT methodology started in 1975 as ‘Prompt’ later being remodelled in 1989 for IT environments and renamed to PRINCE. In 1996 it was relaunched to work for projects of any size in any environment and became the PRINCE2 we know today with regular updates to reflect continuing practices. It is part of the Best Management suite of practice owned by UK Government Cabinet Office and is used in both public and private sectors globally.
Why we chose the PRINCE2 framework for our projects
We wanted to provide a formalised process for our customers and team members and found that PRINCE2 best coincided with our current project lifecycle structure. We do not, however, stick to this lifecycle with iron chains as every project is unique. Due to the nature of our business, we ‘the supplier’ have a relatively short project cycle with our customers and so other sprinted approaches to work doesn’t fit the time span we work to. The work we do is Business As Usual (BAU) for our disciplines but the project content is not BAU for us as a collective, our customer and their clientele. PRINCE2 defines a project as “A temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case”. Projects bring about change; they have a beginning, middle and end while pulling in cross-functional skills. And that essentially is what our work is about. We are generally a small temporary cluster of people, defined by the product we are creating, including; the lead/executive responsible for requesting the product due to a business case and bringing the money, the content owners/lead for users who are tasked with putting the information into the product and managing them thereafter, the design supplier, the development supplier and the development lead. We create a product to achieve an end goal and then we move onto the next project. PRINCE2 gave us the formalisation of the process we needed to create a smoother journey for all parties involved, with accountability and shared goals but still working to the same flow as we previously had to limit change.
How do we fit with the 7 PRINCE2 Principles?
PRINCE2 Principles are the practices we are adhering to whilst following the framework and the purpose for project managing. Their evidence comes from the process set up, the themes that they reflect and the documents that are produced.
Continued Business Justification
Each defined stage asks the question is this still needed? Is the project still viable? We appreciate that projects start funded and can often end without. We also appreciate that the reason the project was embarked upon may no longer be valid. So as stated further along our projects are split into stages and with each stage comes a review of the progress and the project to ensure further development are still necessary and justified.
Learn from experience
Nobody should re-invent the wheel. Likewise, we shouldn’t embark upon ventures we know have failed for our self previously or that others have tried and failed at. The more projects we have embarked upon the more lessons we have on our belt.
Defined roles and reasonability’s
Clarity from the start is paramount. Never presume that everyone knows exactly what you think is happening if you haven’t all agreed to it from the start. Knowing who is doing what and when allows for a smooth journey and ownership of development.
Manage by stages
Stages allow the project to be broken down into manageable chunks, allow for regular check-ups and ultimately regular reviews as outlined above. Our projects are clearly broken down from the start.
Manage by exception
The agreed Project Board will only meet at the end of each stage to give authority to proceed and set tolerance for the next stage. We don’t have unnecessary meetings as we all have a job to do and meetings for meeting's sake have nothing to solve.
Focus on products
The question is never how we are going to do that, it is what do we want to achieve.
Tailor to suit project environment.
Each project is unique. We don’t conform to the PRINCE2 framework with iron chains and we don’t use the same formula for every piece of work. Without tailoring the framework it would become more of a hindrance than a help.
Why are the 7 PRINCE2 Themes important to us?
The seven themes are the cogs in the device or the ingredients in the recipe. They are the parts that are needed to ensure all bases of the project are covered and under each heading are various records, reports and discussions by the several levels of management. Here is a very quick run-through of how those themes form our project lifecycle.
Without some form of a Business Case from the requester we have no grounds to begin a build. There will be no justification on the need to begin the project or confirmation that funding is in place and agreed. Although getting one of these in place can sometimes delay projects starting, it does save time and money in the long run for unneeded work or paying out for preliminary work to a project that is unfunded. Once we have this we can get to work on Organisation. Organisation of the project is different to the organisation of the individual teams. Being able to say at the start we want this project to be completed by a certain date requires that you organise the middle to flow with well laid out Plans. Plans allow for every member to know exactly where we are at every point in the projects. It addresses at what point we will need engagement and commitment from each side to ensure the project sticks to the goal. There will always be Risks involved with a project sticking to design however through these plans we can highlight the risk areas and adjust accordingly should these come to fruition. It’s this risk planning that is key to ensure we are pro-active rather re-active. With the project organised, the plans in place and the risks premeditated for deciding the Quality measurements are crucial. This is deciding how we will know that the project has hit what it had set out to achieve and that it is performing as hoped. These are as simple or complex as our customer would like them to be. Ultimately in the development stage, we see these as the building aims and the project requirements. Now, this all sounds fine and dandy in an ideal world we hear you cry. But things crop up outside the planned risks of a project, stages might take longer than anticipated and extra requirements may be thought of mid project. Therefore we plan in Change logs. Here we can document unpredicted changes that are required and discuss how we will work around them if they can be absorbed, whether we need to add a phase 2 or if it will delay the project. Progress is the final blocking of everything together and explains how we are going to monitor and control the project as whole successfully. Then it’s just cracking on and putting it all to work.
The Agile approach to Project Management
Agile isn’t a fully defined thing, more of a manifesto of beliefs. A lot of frameworks and methodologies like Kanban and Scrum can fall under its umbrella and work for teams of all sizes. DSDM that we go into in more detail below is one of these but we touch upon agile separately to show how we take the whole approach of agile into account, not just the DSDM logistics.
Why we chose the Agile approach for our projects
While each Agile methodology type has its own unique qualities, they all incorporate elements of iterative development and continuous feedback when creating an application. Any Agile development project involves continuous planning, continuous testing, continuous integration, and other forms of continuous development of both the project and the application resulting from the Agile framework which is needed with the fast changing NHS environment and budgets involved.
How do we fit with the principals involved?
Individuals and interactions over processes and tools
Effective interaction between team members is key so the team delivers value to the business.
Once the team gets a business goal, it:
· Figures out how to do the work;
· Does the work;
· Identifies what’s getting in its way;
· Takes responsibility to resolve all the difficulties within its scope;
· Works with other parts of the organisation to resolve concerns outside their control.
Our customer analysis meeting and subsequent team meetings are evidence to this. Although our work follows a path it is all flexible to the customer or project and promotes transparency in its regular meetings.
Working software over comprehensive documentation
Every stage must produce working artefacts. It may not be enough functionality for the whole product to be shipped but there should be working functionality at the end. Meetings are set for the stages and each stage must deliver its product in this time. Documentation on the process is kept to a minimum to ensure the stage owner can focus on the work but still has some documentation for transparency.
Customer collaboration over contract negotiation
We are always discussing and liaising between the team and with customer. Regular meetings are set at the start. Initial analysis works in what each party can provide for the other. Still a degree of contract to ensure it fits with the business plan and the expectations are laid out.
Responding to change over following a plan
The team’s goal is not to blindly follow the plan; the goal is to create value and embrace change. The thought process and ideas necessary for planning are more important than the plan itself. A plan created early is based on less information than will be available in the future so, naturally, it may not be the best plan. As new information is discovered, the team updates the product backlog. That means the direction of the product likely shifts. This continuous planning improves the team’s chances of success as it incorporates new knowledge into the experience. As described the plan is there as a lucid structure to provide a path to work along. This can and will change for each circumstance and the stage meetings allows for this to reassess at every point.
The DSDM approach to Project Management
Dynamic System Development Method
DSDM or Dynamic System Development Method was first released in 1994 by DSDM consortium which was founded by the then software development enthusiasts who were targeting to give a proper structure to Rapid Application Development (RAD) method. It took time to take its current shape and by 2007 it gained good popularity & became a generic approach to project management and solution delivery. DSDM follows a lot of Agile principles and focuses a lot on user and customer involvement.
Why we chose the DSDM framework for our projects
DSDM recognises that most of the issues observed while products are in development are caused because of people problems. DSDM aspires to keep the processes not dependent on tools (so that it can be incorporated in any situation) while helping people collaborate and work effectively. Every project is different and clearly, in practice it’s a good idea to clearly define and agree on the project aims, and get as much information as you can before you start but allow that flexibility for movement.
We think the main point is client involvement with our projects, though we aim for no more than 3 people as we don’t want a committee while retaining some flexibility. Problems occur when:
1) You don’t have clearly defined aims
2) You don’t have enough information to begin with
3) You don’t understand the requirements
4) User can’t articulate the requirements
5) Too many people are involved in the design
6) The goal posts shift and keep on shifting
The point that 80% of project functionality is developed within the first 20% of the time spent is a good one — hence let’s leave some of the ‘nice to haves’ to phase 2, or phase 3 if necessary.
Time and resources are always limited in the public sector hence we can not necessarily do everything in the first phase or should do everything in the first phase and DSDM nicely allows for this fluidity of development in process.
How do we fit with the 9 Principles of DSDM?
End-User is closely involved with the project
You should not go more than a few weeks without having contact with the client whether that is through a meeting, email or phone call as otherwise, the project is likely to stall. This approach helps in building the product as per the end user’s real business requirements, getting quick updates, reduce errors and reduce time wasted in unwanted functionalities.
Empowering teams
Making sure everyone feels empowered to make quick decisions that they feel would benefit the product, team and the business most. It not only entails a feeling of responsibility within every team member but also helps in loss of time in communications.
Frequent Releases and Updates (During Development)
In the old way of working, a prototype form might be developed — without the functionality or a project might be developed in its entirety and then handed over to the client for testing.
This isn’t the desired way according to DSDM. A working model is always better, even if it will need to be changed at a later stage. Keep the users involved. Release an early version of the software, let the users have a play, then revise it and let them have another play.
Development driven to meet business needs
Frequent releases, incremental development tasks make issues/bugs visible at a much early stage in the process. It also helps the technical folks understand the requirements much clearer since frequent releases make them smaller and thus increases on the core functionalities that the teams would be developing in those releases.
Incremental Development
Don’t try to do everything in the first phase of a project — we are limited by time and resources.
80% of the core solution is targeted to be built in the first 20% of the time. If we don’t have time, save some of the ‘nice to haves’ for a second phase. It helps in keeping the complex task easy (by breaking a bigger task into smaller tasks). Also, features and functionalities that are identified as the most important ones are developed first.
Be Open to Change
Developing software is an iterative process. For example, when a member of the team was developing an application for Pathology a couple of years ago, we had about 10 releases before we got it right. Not ideal but we got there in the end! Technology being a rapidly evolving domain, there should be a mechanism to incorporate changes. Even while developing the product, sometimes the requirements identified in the beginning may not remain the same as the product evolves.
Keep Initial Requirements at a High Level
Do not try to spec everything upfront in a totally rigid manner. There are always things which need to be changed or we’ve simply forgotten about. While beginning the product development, the practitioners advise keeping the requirements simple and at a high level. Getting deep into the requirements right in the initial discussions doesn’t help since the solution (and thus the requirements) evolve as the product takes its shape.
Efficient integration between development & testing
DSDM emphasises on having a small team, high level of communication with those teams, and efficient integration between the team members. Traditional methods involve testers at a much later stage. Thus, any issue if identified took a lot of time to get resolved. In DSDM however that issue is addressed, and testing of the solution is started as soon as the development activities are started. We pass tasks through a process of testing with a member of the like-minded area to confirm that code is sound, and nothing has been missed before going to a front-end developer for visual checks and usability. Only when all the tasks of the stage are completed can the user then test from their perspective before sign off can be sought.
High focus on team collaboration and cooperation
An atmosphere of trust and honesty is observed within the team. Daily calls and discussions on issues that teammates are facing are helping in quick issue resolution and thus development of the product more efficiently. As a team we split time between being in the office and working from home. Home days are usually for getting our head down and office days are focussed on collaborations and discussions, but we are always available on chat, email or call.
To conclude…
Both methods marry quite well with each other. We take the small chunks, flexibility and team-driven approach from DSDM and the documentation and staged approach from PRINCE2. We think this mix of methodologies fits our teams’ goals of ensuring sustainable high spec products are delivered that meets our users’ goals. Our approach is always under scrutiny and is reviewed annually at our team goal setting meetings.
Published by Rebecca Wootton on 24.09.2020
Becky is our Team Leader and Web Developer. She has been working within the Webteam since July 2011 and her role includes managing and supporting the whole team and developing the infrastructure of websites and ensuring sustainability. Becky also has Level 3 qualification in Education and Training, Level 2 qualification in Customer Service, PRINCE2 Foundation and Management Studies certificate.
