This week it was revealed that car hire company Hertz has sued Accenture for US$32 million for failing to deliver either a functional website or mobile app during a 16-month digital transformation project.
While there is a lot that could (and will) be said about this. It’s quite remarkable that even now digital and software development projects are still being carried out using traditional ‘waterfall’ project management approaches with all the design and planning done up-front rather than using an agile, just-in-time approach.
Fixed or variable?
In every project there are four key elements:
Features (requirements)
Time
Resources (cost)
Quality
Whether these elements are regarded as fixed or variable is what distinguishes one project management methodology from another.
Traditional
In so-called ‘traditional’ or ‘waterfall’ projects features are fixed.
Requirements are gathered, plans are drawn up and the project does not finish until the last feature has been delivered.
If the project goes off-track, more money and resources are thrown at the project and the deadline slips further and further away.
As projects get later, often quality also suffers, as this cartoon demonstrates:
This is what happened to the Hertz/Accenture project. Started in August 2016, a new website and mobile app were meant to be launched in December 2017. The project was abandoned in May 2018. Nothing was usable; nothing was launched.
Agile
In contrast, an agile approach to project management fixes time, resources (cost) and quality. It is the features that are variable.
A minimum viable product (MVP) will be delivered quickly, tested with real users and iterated on to bring more features to market incrementally.
Time is fixed using fixed-length sprints. Resources are fixed using established teams who stay together for months. Quality is fixed by establishing good testing disciplines, agreeing on common practices, and establishing a solid definition of done.
There is an old military adage that even the best plan goes awry after the first contact with the enemy. So it is with projects: there ought to be an expectation that features will evolve and change as you learn more about the product during development, user testing and once those new features have been delivered to end users.
As our own agile journey continues, we would benefit from bearing in mind the eight principles of the AgilePM framework:
Focus on business need
Deliver on time
Collaborate
Never compromise quality
Build incrementally from firm foundations
Develop iteratively
Communicate continuously and clearly
Demonstrate control
What next?
The Vision Tasks team has recently delivered v1.4 to SIT and ELS. This is a major milestone for the project and a huge confidence boost for the team. (Well done, Tasks team!) This is a fabulous foundation on which to build, incrementally.
Over the next few months, I’d like to see one of the focuses for the team to be working towards being able to deliver releasable features at the end of each sprint (even if they don’t immediately get put into production).
There is some work to be done first to get us to that point but that’s the goal: steadily delivering quality.
I’m currently building a website for a friend of Jane, using the Divi theme from Elegant Themes. The website is for a holiday property letting company. This post explains how I changed the built-in Projects content type to Properties, and how you can change it to anything you want.
The problem
Divi is a great theme to use: it’s very flexible, it’s responsive (so it works equally well on smartphones as well as huge desktop monitors), and it has the easiest, drag-and-drop editor that I’ve ever used for WordPress.
Divi comes with a built in content type called Projects; WordPress calls them ‘custom post types’. I use this content type on my own website to list the various projects that I’ve been involved in over the years.
As you can see from the WordPress admin menu ‘Projects’ appears on the list beneath Posts, Media, Pages, and Comments:
WordPress menu with Divi installed
Divi also ships with a number of attractive ways to display your projects using its Portfolio and Filtered Portfolio modules. You can even display these full-width or as a grid, such as this:
Demo of Divi’s Filtered Portfolio module displayed as a grid.
These are exactly the features that I’d like to use on the property letting website:
Keep properties separate from pages and posts, using a custom post type.
Display all properties in a grid.
Allow users to filter properties based on the categories that are assigned to them.
So, I want all the features of Divi’s built-in Projects custom post type, but I don’t want them to be called Projects. I want them to be called Properties.
Use a child theme
First, I strongly recommend that you use a child theme when customising Divi (or indeed any other WordPress theme). A child theme inherits the functionality and styling of another theme, called the parent theme, and allows you to make local customisations to it which will not be overwritten when the theme updates.
I copied the code, added it to the functions.php file in my child theme, and set about editing it.
remove_action / add_action
In a nutshell the code from Elegant Tweaks does two things:
It defines a new function — called child_et_pb_register_posttypes() — that will redefine the characteristics of the Projects content type.
It removes the default Projects custom post type contained in Divi, and replaces it with our one in the child theme.
This last point, I believe, is simply to be tidy: rather than clumsily overwriting the existing ‘project’ custom post type it gracefully removes the old one, and creates a redefined version in its place.
Labels
In that Elegant Themes post the author was only concerned with changing the URL from /projects/ to /photos/. So in his example, the names used in the WordPress admin screens still referred to projects: Edit Project, Add New Project, etc. But I want to change these too.
In the code for a custom post type these are referred to as ‘labels’ and are defined in the $labels array. This is what my code looks like now:
As you can see, something I find useful is to list the elements alphabetically. Personally, I find it easier to work this way; your mileage may vary.
Obviously, if you are customising this for your own requirements simply edit this to reflect your needs.
Custom post type options
Next, we define the arguments to be passed to the register_post_type function. These define not only how the custom post type is used but also how it is displayed in the WordPress admin menu: where it sits and what icon it uses.
Slug
The most important option here, for our purpose of customising it, is the 'slug' key. You must set its value (in single quotes) to whatever you need it to be. In my case 'slug' => 'property'. I’ve highlighted this in the snippet below.
Just make sure you don’t set the slug to the same name as an existing page.
Menu icon and position
One useful new addition to the code provided by Elegant Tweaks are the options to set the menu icon and where it sits on the menu.
As these are properties I decided to use the home dashicon.
dashicons-admin-home
I also decided to move it up a bit, from beneath Comments to immediately below Posts. WordPress uses numbers to specify where custom post types should sit, e.g.
5 — below Posts (this is where I want it to appear)
This tells WordPress to apply all of these options to the ‘project’ custom post type.
Because we are redefining this existing custom post type (by changing the URL, the menu labels, the menu icon and position) it means that everything else (the default project page layouts and portfolio modules) will work as expected without any further customization.
Categories and tags
The rest of the code I left untouched. This code defines the categories and tags to be used with the projects/properties custom post type.
How it looks now
Adding all the code (see below for the complete script) this is what my WordPress admin menu looks like:
Divi theme now with Properties instead of Projects
That’s now working as I expect it. Job done.
Complete code
Here is the full code that I have in my child theme’s functions.php file:
Like many things on my blog I’m primarily putting it here for my own reference, but if you find it useful — or would like to suggest improvements or additional features — please leave a comment below.
This plugin allows you to use the Divi builder for Posts, or indeed any custom post type.
Update 3: Fix for Divi 2.5
Saturday 26 September 2015
I’ve now (finally) updated the code to make it work fully in Divi 2.5.
In the end it was quite simple: the add_action(...) and remove_action(...) priorities were wrong in my code. These tell WordPress in which order actions should be executed.
In my previous code I was instructing WordPress to unload the default Divi project custom post type before it had even been defined.
The default priority value is 10; I’d set mine to 0 and 1, respectively.
A huge thank you to Craig Campbell for his excellent Chrome Logger extension and ChromePHP class — two tools that greatly helped me work out what was going on.
Great to see that the latest update to Firebug has fixed the issue that I reported about it breaking when you opened Firebug in a new window (see Firebug bug at the other place).
Next up, I hope that the alignment of menu items gets fixed in the next update to the Web Developer add-in … it’s just annoying!
Here’s an example (above). You can clearly see that the icons aren’t equally aligned on the left.