Project Management Tools And Why Being Highly Customizable Can Be A Bad Thing
“This is a common pattern in the evolutionary process, [Simon] Wardley said [researcher at the Computer Science Corp]. The more customizable a technology is, the less agility users will have, because IT will spend all day customizing the tools instead of solving the problems. Standards increase efficiency, he said, and current cloud platforms offer extreme customization options. All of this translates to slower velocity, he said; standards come from best practices, and best practices eliminate waste.” BSA warns of governments interfering with the cloud, SD Times, March 2012.
I was always annoyed by the fact that I didn’t take my Microsoft Windows PC and customize it using all the bells and whistles it provided (themes, desktop pictures, screensavers, gadgets, scripting, etc.). I wasn’t getting all the productive benefits of my PC, I felt, because I wasn’t using everything provided. The catch was, I noticed, that everytime I customized what I had, I seemed to eventually lose it. If I were to upgrade my PC or just use another PC, all my customization was stuck on my old PC. Customization didn’t follow me. So, it was just easier to use the “out of box” configuration and work with that.
So I found myself reluctantly agreeing with Simon Wardley above, that using standards (and standard configurations) on software tools generally is the more productive way to go. My gut still tells me that I need to get better use out of my tools by tweaking them to be just want I want them to be, but the specter of losing all that work looms too large for me to do more than the most critical customizations.
Cloud based computing has helped overcome some of this. I love the fact that when I move to any machine (PC, tablet, phone), all I have to do is log into my Google account and I have my whole environment available to me. Of course, I’ve turned over major customization and upgrading to Google, and they have a tendency to add new and retire old features. I’ve simply replaced my own IT department with the Google IT department, and there really isn’t anyone I can talk to directly when things aren’t working. Instead, we talk in forums and exchange problem solving lessons learned with other users who have worked out solutions to common problems. However, the Google “standard” is reasonably efficient and effective and what I gain appears to be a lot more than I lose, so far.
I once spent considerable time programming Visual Basic for Applications (VBA) to exchange data with Microsoft Project (VBA is built into Project as it is other Microsoft products). I would program VBA to send out reminders to project teams (through Outlook e-mail which is also VBA enabled) that tasks should be complete or to request status updates. I would also pull in dependencies and progress from other Microsoft Project plans using VBA programming. This gave me a way to “loosely” couple my plans with other plans (i.e., we did not have hard dependencies between us but their progress or lack of it helped or hindered our progress). This all worked very well, but it was a lot of overhead to maintain and every time something was updated (Outlook, Project, server locations, IT naming conventions, etc.) I had to spend considerable time “fixing up” my mashups so that they would continue to work.
I often say that while I love tools we can often spend too much time wrapped up in the tools and lose track of the purpose of using the tool. This is, in my experience, due to the customization paradox that Simon highlights. However, a good tool with a mature and insightful “paradigm” (or standard) for doing the work we need to do can make a huge difference in our productivity. We do have to learn this new approach, and that is always a challenge, and a lot of approaches can be too stilted and not appropriate to what we need to do. Finding that appropriate tool, by shaking it out on a few pilot projects, can be one of the best things we can do to help ensure successful projects.
As one advertisement in the same SD Times issue said “Everything You Need To Ship Software OnTime. Powerful bug tracking. The best Scrum tool. A beautiful & fast UI.” Now I know that to get the most out of such a toolset, it first should have a good standard approach that I don’t have to customize too much to be immediately productive. If a tool’s power is touted as its “flexibility” and “customizability” then we might want to look closely at the total cost of deploying such a project management tool.
Do your project management tools help you manage your projects with only a minimal amount of customization?
7 thoughts on “Project Management Tools And Why Being Highly Customizable Can Be A Bad Thing”
Comments are closed.
More comments from around the web:
Clifford Shelley • Good post – software people tend to spend far to long sharpening the axe and not long enough using it (me included).
There is another matter to consider too – commonality, whether defacto or using formal standards gives comparability. A common terminology, vocabulary and expectations gives us the ability to share project information quickly and easily. We learned this developing our own PM tool (us, sharpening our axe). If all projects use the same overall structure and ‘signalling protocols’ so we can interpret info similarly there are major gains. The problem is – everyone wants to tailor thte commonality out of their tools. The trick is to set the degree of commonality at the correct level and not constrain work unduly.
Bruce Benson • Clifford,
Guilty! One of the pitfalls of customizability is the sense that if the product is customizable … well … we should customize it! The thinking is we’ll get more for our investment that way, but often it can be a time sink that makes the investment less cost effective.
Agreed. Standards of some kind (vocabulary, concepts, interfaces, data, etc.) can make a huge difference in how well teams/organizations work together. The problem as you mention is the perceived need for things to be “unique/differentiated” and that works against any such standardization.
Standardization should be the baseline but not prevent adaptability and innovation. While these will add costs, the notion is that they’ll become the standard baseline for all eventually (the ones that work out) and we’ll see the full benefits for everyone. The trick always seems to be how to balance the two.
Thanks for the feedback.
More comments from around the web:
Douglas (“Dougal”) Lawson (douglawson@btinternet.com) • Dangerous to customise management tools and therefore dumb.
A management tool must be available to share; so one must use the vanilla “out of the box” set up to avoid wasting time.
One does not change the clutch, brake and accelerator pedals on a car depending on the handing of one of the the driver users.
As for these eejits that alter the handing of their mouse buttons, these people need to get a life.
Bruce Benson • Dougal,
Well, I suppose if someone wants to spend the time, why not ;-).
I will say that I had to try a lot of customizing to appreciate the real cost of doing such a thing. Some of it is useful/highly cost effective and one needs experience before being able to get that kind of value out of customization.
With that said, I would rather have tools that do very useful things “right out of the box (or the cloud, etc.).” We have enough best practices in the world that tools should at least support those easily, and then allow customization for that 5% where it is worth the time and effort to make the change.
I don’t even mind the ability to customize and risk the costs, if there is a quick way to reset to a standard and/or a way to migrate the changes to new versions or different hosts/workstations, other projects, etc..
Thanks for the feedback.
Comments from around the web:
Chitralekha Das • I agree.. Standardization is way to go.
The challenge is everybody needs to share the same thought.
Steward Copper • Maybe I don’t 100% right but when you have many customers and more than 5 projects you need a PM tool with certain level of flexibility. You need to have the opportunity to follow more that one workflow.
Bruce Benson • Steward,
Agreed. Ideally a tool will have the ability to easily, without a whole lot of customization, support those workflows. Hopefully, the tool and the workflows reflect a way of doing business that matches known current best practices.
Getting everyone to agree to those practices (Chitralekha’s point) is often half the battle.
The other half of the battle should not be the need to highly customize the tool to get it to support even one of your workflows. I’ve seen some tools that need so much customization, that we might as well just code up something ourselves, since the effort is the same (a few scripts, simple interfaces, etc.) and we can do exactly what we want that way.
The summary notion is to beware of tools whose only real strength is their *potential* to do whatever we need them to do. I’ve had senior managers get excited about tools because of their “flexibility.” They seem to think that flexibility comes with little cost when in fact the cost if often high AND what the tools does is rarely, after that cost, exactly what we need it to do. Just because we can get it to generate metrics from the workflow, might not mean that we can get it to compute our Scrum velocity or show the backlog the way we want to show it (and have been showing it using more manual approaches).
The tools that best match, out of the box, what we need them to do, are often the more cost effective tools to put into use.
Thanks for the comments.
Avi,
I do like the trend towards exporting and smartly importing configurations. When it comes to workflows and other more scripted changes — especially between tools (not from the same vendor) that becomes more challenging.
I do like products as a service (online/in the cloud) for their flexibility when it comes to location and access. I would like to be able to completely export my work/configuration and be able to then import it again (or into another tool!)
I was intrigued by “And The Occult” on your website, but didn’t have the opportunity to drill down.
Thanks
Shoumik,
Vendor customization is approach that is often used (prior to delivery or on-site, with our teams).
The only caution is that we are paying for the customization (so we are not doing it and learning the tool) and if it does need vendor/contract support then it will probably need it in the future when we need to make changes (are they on-site or overseas, cycle-time for changes, agile vs waterfall delivery, etc.).
Nothing wrong with any of this, if we acknowledge that this tool has this cost. Clearly if the tool, out of the box, already does what we need (or is very close) than we can more quickly get productive and more quickly see a return on our investment in the tool.
The caution is in adopting the “OK, we can tweak this to do whatever we need if it isn’t quite right” mindset. This is often a slippery slope and has been the root cause of many tools never achieving their objectives (“Sure you can make it do that. We have a built in scripting language! NOT!”).
Good point.
Most software today offers you some way to export your customisation. You can customise nearly everything about 3D Max, for example, and you can save those features that you changed, and import them into a fresh installation.
I do agree that most software tools are probably best left in their out of the box configuration and, in most cases, that’s more than enough 🙂
Avi Kaye
Online Project Management
http://www.happytodos.com
One option would be that vendor provide customized software.
Software product vendors will generally create a generalized software that can be customized that fits for individual(organization).
For example when you purchase your laptop from Dell you have option to buy pre-configured or customized devices.
Software Vendors should provide similar options where the buyer can set their expectation(or objectives).
This way the user of project management tool can focus on their business while the configuration remains the business of software vendor.
This might cost the extra buck but I think will be nominal as compared to the value.