When you’re contracted to build a solution for others – primarily on the web since that’s the area in which I work – I think that there are a number of factors that are important for a project:
- There should be no “design by committee.”
- No one else other that the core development team should be able to provision development, staging, and production.
- No one should be able to write to production but the development team (and even then, there should be a deployment process).
I’m always hesitant to make statements like this as they come off as dogmatic, but I find that the longer I work in this industry, the more I think these three rules are important.
Or perhaps they are really just guidelines. After all, there are shots called before we actually get stuff done.
Regardless of if they are more suggestions or rules doesn’t really matter. There are reasons that we all arrive at the conclusions that we do, right? And so over the next few posts (rather than one long post), I’ll share the reasons I’ve found these three rules to be important.
Design By Committee
When using this term, I don’t mean that a single person should be responsible for designing a site. I just mean that an agency or a group of those who focus on design should be responsible for it.
Design by committee is a disparaging term for a project that has many designers involved but no unifying plan or vision.
So a “committee” in this case is when a group of people, or the customers or those related to customers to some capacity, come to view the result of the implementation (or even just the design), email suggestions of what they’d like to see and expect it to happen.
That is, the expertise if a given designer is sacrificed for the opinions of another group.
And, perhaps in extreme cases (though I’ve never personally experienced this), use payment as leverage to get their way.
The thing is, the people who are contracted to design the solution for the customer should be, as stated, experts in the field. They understand typography, colors, screen resolutions, accessibility, and so on.
Leaving them to their area of expertise is always a good idea.
Taking Care of The Project
None of this has to do with anyone having more control over the project than anyone else.
It’s about making sure that all of the project’s stakeholders are working in conjunction with one another and not crossing areas of responsibility. (Imagine, say, the GIFs that would be used for advertising if developers were responsible for commercials. 😏)
The bottom line is that a successful project is just that when everyone stays in their corner and works together in their own area of expertise.
Otherwise, you end up with things falling out of sync and basically creating more problems when there were none (well, at least in a particular area) with which to start.
In the next post, I’ll cover the idea of provisioning environments, what this means, and how it plays into the overall role of project management. But I’ll go more into detail about that in the post.
Ultimately, it’s about making sure who has read and write access to the various areas in which the application or project can be deployed. Sure, for some reading this, this might feel a bit like “beginner” content or not like “development” related content at all.
But if you’re in the business of working with others to build a solution, then these are things you’re likely to run into and it’s easier to have a plan based on the mistakes others have made (namely me 🙂) than learning things the hard way.