In the last 10 years, I’ve had the chance to wear many hats — including that of developer, project manager and, now, CEO (the latter blows my mind still).
Experiencing both sides of the coin has given me a much rounder perspective on project management, especially when it comes to the world of web development.
Since sharing is caring, here are a few rules that have helped me bolster development in my team and ensure the success of the projects we’ve undertaken at Digitally Tailored.
“Nothing” Adds up to Something
We are all familiar with the one-to-ones and the project meetings where deliverables are discussed and timescales are set down.
Careful planning is essential to a project’s success and, when you’re a start-up, it can be key to your company’s survival.
During these meetings, one pattern often arises — and that is how quickly someone will fob off certain tasks as ‘nothing’.
Things such as changing a bit of text, adding a tracking code or changing the year in the footer can, yes, be done very quickly, but nothing can be done instantly.
And, before you know it, these mundane tasks have added up to a whole day’s worth of work. This is especially the case when you consider the overhead of finding the correct source on the site, preparing the environment, testing, deploying and project administration (got to close those tickets!).
If you several developers adopting a similar approach to their work, the problem quickly adds up. Very soon, you have a project that is waaaay behind schedule and, if you are an agency, a client who is suddenly dubious of your company’s competency. The last thing you want is for your client or customer to be questioning whether you’re the right person for the job after all.
It’s not all on the project manager either, it’s very easy for a developer to think of those tasks as mundane and, consequently, not allow enough time for them.
Focusing on your overarching goals is important, but taking the time to allocate resources appropriately equally is.
The Elusive Flow State
This is not limited to programming, but when it comes to a developer’s productivity, it’s a “make or break”.
We all know that the procrastination monkey does not help achieve those much-needed project milestones, but in my eye, the biggest culprits are the multiple 2-minute interruptions that we are constantly subjected to when working in an open-plan office.
Asking a quick question can have far more detrimental effects than it might seem.
Sure, those small interruptions last only a few minutes, but a study by University of California, Irvine shows that it takes an average of 25 minutes for the brain to get back into a focused zone.
It’s one of the reasons that I and many development managers encourage businesses to support remote work.
Unfortunately, we’ve still got a long way to go before some businesses and their project managers ditch the micro-management approach and focus on deliverables instead of bums on seats.
The physical distance from a usually open-plan office combined with a programmer’s ideal working environment is the perfect location for them to knuckle down and get in the zone.
While I’m not saying we should all send our employees home and do remote work, I do believe that remote work needs to lose some of the stigma that is attached to it and that businesses need to reconsider whether their current office set up is not causing losses in productivity.
New tech is cool. Existing tech is proven.
Some businesses will list the software requirements in their project spec. In certain cases, those requirements are perfectly justified. In others, it amounts to a need to impress with the latest tech or development trends.
New tech is great, and the shift towards centralised solutions (Python for data handling, JavaScript for entire web stacks and micro-services for almost everything else), has its advantages. University curriculums have updated with the times and very few still teach the 20-year-old solution that is PHP.
Yet, I find myself using PHP for a lot of projects. PHP is all over the web because it was the first tool that offered truly dynamic content generation. Despite now having competition, a large number of key software providers still use it (Drupal, WordPress, Magento, Joomla etc). Additionally, finding resources and developers to work with PHP is simpler which often has a direct impact on costs.
Instead of focusing on what the latest programming language is, think of what your requirements are, and based on that, what would be the most efficient software to use.
Don’t Reinvent the Wheel, but Beware of too many Third-Party Solutions
Not everything has to be done from scratch. Where possible use existing solutions to meet your goals. Let the devs spend more time building the unique aspects of your product. There are so many libraries, free resources and paid services that can help you achieve your goals. You can then spend more resources and time on creating something that no one else has.
However, be careful to not overindulge in existing solutions.
Using a bunch of different third-party software to piece together your product and crossing your fingers that all will seamlessly integrate usually results in a Frankenstein product that drains resources on repairs and fixes.
As a project manager, you need to have the ability to gauge when to use what is already available or to develop something from scratch. Taking the time to do your research, consulting your dev team and understanding the limitations of existing solutions can greatly speed up product delivery.
The 50% safety net
Whether it’s overconfidence or not considering the requirements surrounding the completion of a task, in my experience there is little to no harm in adding a 50% time buffer on-top of all developer estimates. I encourage developers to adopt this in sprint planning where possible.
From a project management point-of-view, this also works the other way around. If a deadline is in 3 weeks then the timebox for your development spend should be 2 weeks. This captures testing and additional requirements from outside of the development team, which almost always arise.
The Eternal Quest of Fathoming the Issue
By far, this is one of THE most frustrating aspects of a developer’s work and I think I can illustrate my point best in the following example.
Consider this email landing in a developer’s inbox:
“Hey James, really sorry to bother you, but the “quote form” on the website is not working. Can you please take a look. Tom needs it for his call with Generic Company LTD at 3 PM. Really appreciate it.” Sent by Ashton, project manager at 1 pm
Ashton, the project manager, is polite and attempts to be informative, but for James, the developer, this message does not help with the issue, other than saying that there is one — somewhere.
At best, here are the 2 things James can gather from it:
1) An important feature that supports business sales is down
2) If it’s not fixed by 3 pm today, we may lose a client
So James drops everything he’s working on, and begins the Eternal Quest of Fathoming the Issue by initiating a back and forth conversation with Ashton to understand a variation of the following:
- Who and how many people are experiencing the issue?
- What type of user are they? Are they internal to the office or are they a potential customer?
- What error was shown, if any?
- What was filled in?
- When did this happen?
- Does this always happen?
Ashton, the project manager, is probably having to forward some of James’s questions to Tom who reported the issue in the first place and then get back to James.
If James had all of this information at the offset, he could potentially pinpoint and solve the issue before 3 pm, but, in this instance, precious time is being spent on investigatory purposes.
As a project manager, consider introducing a feedback loop and template that all members of staff have access to. This helps mitigate repetitive tasks and unnecessary investigation when issues arise.
As soon as someone identifies a problem, filling a template that looks a little something like the below can help James fix the issue in half the time:
- Problem description
- Error shown
- Link to page
- User type
- User ID or link to account
- When this happened
- Is it recurring
- When is fix needed
There are a couple of assumptions in the above so it’s likely worth customising this to fit your business needs.
Ensuring that all of these details are provided through a feedback loop can save both development time and time for the person reporting the issue.
This can be in the form of an email template, a chat message template, or my personal favourite a board ticket template.
Making sure that all members of staff understand the importance of filling in the template is key. Once implemented, the metrics will speak for themselves in no time.
Here you go, here are a few tips to streamline processes in the workplace, maximise on productivity and make your developers’ lives easier as well as yours. Ultimately, these things help you ensure the success of the projects you are responsible for.
