Ok, here’s the situation: you’ve started your project, currently your team has frontend developers and backend developers. Everyone is happy and doing their parts.
What happens when the pages are ready for implementation?
You guessed it, it goes to the hands of the backend developers who will do their magic: create the components for choose your favourite CMS here.
At this point we’re still happy, everything is working just fine and the project will be delivered on time.
A couple of days have passed and some JIRA tickets have been raised: we need to fix something in the frontend.
No problem, the frontend developer will open up the HTML files and do the proper edits.
Iteration two hundred seventy six
At some point between revision 1 and revision 276 someone updated the backend CMS component and not the HTML static file. Probably the change was simple enough, there was no need to involve any frontend dev.
That is actually fine! It’s way cheaper, project-wise, and faster to develop.
Now, be careful, that decision might cause a lot of trouble in the future, when new major features will need to be added. An out of date slices will force us to download source files from production. We all know those files can be messy, with random ID’s everywhere, extra empty divs, inline styles, uncommented code…
So, what’ the proper way of applying frontend changes?
Also, if the project has enough budget to have a frontend developer on board, the above workflow is useless. Just send everything to the frontend dev.
Try finding balance!
This best practices should not be a burden, if you get used to it I think you’ll get real benefits. If someone is capable of changing a component’s markup, is also capable of editing plain HTML files.
You should always keep your static HTML files up to date. Not with content changes but markup. I’m not saying it’s easy or cheap but it’s the right way to iterate. Not all projects will have the budget or client will to maintain this code standards. We, as professional, need to advice and convince our clients this is mandatory. In the end, it will probably save them money.
I hope now you have better insight of how you can be more productive and have a better future-proof code in your projects.
Have something to add? Leave a comment down below.
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.
The method focuses on control and communication, which means that numerous deliverables are required:
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.