Tools and processes are great things that can gain you much in terms of productivity. There’s a funny thing about them though, and that’s this: every tool and process you adopt actually *costs* you time. You have to spend time implementing it, learning to use it, maintaining it. The magical balancing act is identifying what tools fit in the magic window of gaining you more than you lose. There’s an ongoing story about this very thing going on over on the Agile Management blog titled Team Frustration Server. In their example, they’ve chosen a great tool- but the tool takes up a lot of time to maintain and a lot of resources, and in some cases is getting in the way of their business. While I hope and believe that they’ll get their project on track, it’s still a great example of how the hidden TCO of some tools can be wrong for the size and speed of your particular organization.
Here’s some things to consider when choosing a new process or tool:
- How much does it cost?
- How much effort does it take to implement?
- How much effort does it take to maintain on an ongoing basis?
- How flexible is it? Can it adapt to new processes?
- How much work will it take to adapt it when our needs change?
- How much effort will it take to abandon it when and if it becomes outdated for our needs?
Remember- if it costs you more money and effort than either you have available or than you are going to save to put it in, keep it in, or rip it out, you should eliminate that tool/process as an option on your choice list.
Like this post? Buy me a cup of coffee.Popularity: 10% [?]
This blog is written by me, Stacey Douglas, an analyst, project manager, systems designer and executive in the software industry. You can learn more about me at my website, http://www.staceydouglas.com.
Pity! You’ve misinterpreted what I posted. While TFS might be frustrating, the resource drain is most definitely not causing our projects to be late or off track. In fact, the opposite. We couldn’t run our business without TFS. We just wish the TCO were lower and the level of commitment required from management to be lower. My conclusion is that many managers will not have the will power or political capital to make a TFS implementation work to its full potential.
David
David,
Congratulations on your success! The tone of your post made it sound like a pain point. Frustration, you must admit, is a word not normally used in a positive way. I didn’t mean to imply any failings to your project; it just brought to mind an important point that I wanted to talk about.
The point of my post still stands clear, I think, although if you’re now happy with TFS, then it clearly does not apply to your group. The right tool for the right job is very important. The biggest hammer is not always the best solution if your team does not have the muscle to lift the hammer, as it were. If you didn’t have sufficient resources and commitment to handle TFS, then it would not have worked out for you.
We have this very issue brewing in-house right now where I work. We have some business groups that want to adopt certain technologies based on the software brochure promises; my fear is that it only appears to meet our requirements, and the TCO is above our current resource capabilities. I’m working on pulling together a requirements gathering and analysis meeting to make sure we’re doing the right thing.