Over the past 10 years we have been involved in a whole host of CMS/DAM/web implementation projects of many different kinds (clients of different types and sizes, as a prime contractor, a vendor integration partner or onsite with the client’s teams), and throughout that time we have always stuck to a single mantra: deliver with efficiency & quality to guarantee maximum customer satisfaction.
No matter what constraints we have faced in terms of managing the different projects, we have had to adapt and adopt. It has never been our goal to simply turn up and impose our rules, and it goes without saying that project management is deeply intertwined with corporate governance and enterprise policies.
In that sense, our project managers have their own cultural backgrounds that constantly enrich our internal Project Management Practices. Their principal goal is to deliver “good work, on-time and on-budget”.
We have nonetheless had the latitude to come up with our own PM approach, notably for fix-time projects. We made the decision to rationalize our position by taking account of 2 fields of perception: observations and corporate values.
Perception is where you look and how you look.
First of all let’s talk about our observations
- A software development process should be undertaken within the framework of a broader business commitment. That is why it is vital we understand exactly where the needs are coming from.
- A more easily accessible knowledge, a Do-It-Yourself attitude and the product-oriented marketing have led everyone to think solution before needs, and unfortunately the vital phase of defining the real needs is sometimes skipped altogether.
- Methodologies and organizations are intrinsically linked by culture, people and processes.
- Agile methods demand mature relationships between business and IT, something which is often underestimated.
- Corporate governance policies demand structured and uniform reporting procedures in projects that influence the choice of methodology.
- Profound shifts don’t happen overnight in big organizations.
- It is important to remember what the initial idea was: why are you doing the task in hand?
- We can’t expect an all-encompassing model from the start.
- The same tool in a different context can generate different results.
- The requester has a good reason for making his request. Respect that.
- Academic project management methodologies offer a starting point, but sticking to them reduces the scope of possibility.
Now let’s us introduce you our values
- A good working relationship with a client is based on a constructive company-2-company relationship, structured team-2-team cooperation and a fair individual-2-individual collaboration.
- Remember that you will learn from your initial choices.
- Share the same goals and support one other.
- Resolve situations that sap your time and energy.
- Choose the right tool for the right job.
- Don’t use all the colours just because you have them on your palette.
- Make sure you are on the right track.
- Guarantee a common understanding.
- Demonstrate agility with the product, the method, the organization.
- There’s always somebody that will use your product, and somebody that will maintain your software.
- Listen carefully and respect other people’s constraints.
- There’s no bad methodology, there’s no best methodology, there’s no point confronting waterfall and agile. Choose whatever solution works best for the situation in-hand.
When you are playing the software development game your secondary goal is to setup to play the next game.
Alistair Cockburn, Agile’s father
For our project management we deal with 2 dimensions
Driven by our enlightened understanding and inspired by the values of objectivity, efficiency, openness and honesty, our project management approach has been broadened to encompass two dimensions.
A cooperation framework for a future proof collaboration
Focusing on controlled planning and on broad and transparent communication, this approach is used to build a relationship with the client during first-time projects, one-shot projects or when handling program management issues. Based on waterfall methodologies, the phases are clearly defined and sequential:
- Initiation to guarantee a shared understanding of the needs , expectations and perspectives;
- Planning to reach an agreement on scope and timing, organization and risks;
- Controlled & Monitored Execution with open communication & fast feedback, with close cooperation during the testing phase.
The aim of this framework is to identify the best way of working together in conjunction with the client. The approach is consequently a circular one, paving the way for the next project by means of an extensive closure phase to assess lessons learned and review the next steps.
- Engagement framework
- Project Statement Of Work
- Functional Contract, Solution design & Detailed planning
- Monitoring reviews
- Issue tracking with JIRA
- Product evaluation & acceptance report
- Project closure record
A fast-delivery framework in a mature relationship
Usually adopted when a mature working relationship has already been established with the client over the course of previous projects, this light and agile method demands a clear commitment in terms of roles and responsibilities. Guided by iterative development and agile methodologies, this approach is based on iterative cycles backed by delivery contracts:
- Inception to define high-level requirements & engagement;
- Elaboration using the iteration plan;
- Execution involving strong collaboration;
- Transition to review delivery and acceptance;
- On-going assessment for strategy assurance and scope refinement.
The method is suitable for product enhancements (change management) or large roll-out projects that involve adding new features to a central environment based on new needs highlighted by a country/division assessment. These iterative cycles can also be run in parallel within the framework of a larger program. That is why the method is based on a light and versatile organization:
- One project master, responsible for scope, communication and planning;
- One product owner, usually a client representative or a commission agent, who can make quick & firm decisions, ensure that the functional strategy remains consistent and accept the deliverables;
- One technical owner who plans and takes action in order to deliver on-time (this is usually a lead developer who is directly involved in the build).
All kinds of additional players may get involved at specific times or for specific reasons. The initial statement of work is put together when the project first kicks off, and then all subsequent communication is handled through our JIRA environment until the project is formally closed and the evaluation reviews are completed.
Our years of rich experience have shown us that these 2 frameworks can cover most situations, as long as the client doesn’t ask us to follow their own policies. Project management is not a science, it is simply good sense driven by experience, basic techniques and positive collaboration.