At the company I work, we are really wanting to get into the agile methodology for developing software. One thing that I'm not excited about is the fact that management wants us to build a custom project management feature inside the company's Intranet.

I think this is a total waste of time. There are many great third party tools available (e.g. Axosoft OnTime) that can do everything we need, and more. For how much development time it would cost us to build our own project management module, we could buy numerous licenses for a third party product.

One concern is that, whilst we are writing code for a client, and using our custom Intranet project management module, we find bugs in the module that need fixing ASAP. That means having to stop work on the client code to fix the Intranet. That just puts shivers down my spine.

Another worry I have is lack of functionality. This custom module is going to be so basic, that it will just feel really crap to use. That might sound a bit snooty, but for goodness sake, many third party tools are so feature rich, that the idea of having to write our own tool makes feel very uneasy. In fact, I can't be bothered.

What do you guys think?

I'm going to raise this issue with my boss, since I feel it's such an important topic to talk about.


Thanks for the great responses, much appreciated. To summarize some of them:


Naturally my boss does want to save money, by not forking out a few hundred £'s for licenses. However, for us to write a custom tool, it will take x number of days, multiplied by approx £500, which is our costs. I don't see the business value in this.

Management have mentioned that they want to sell the Intranet as a product in the future, but it's so custom to our needs (and downright basic), that in order to give it to another client, I can see us having to fork a version of the code and rebuild the majority of it anyway. So it's not like we're gaining anything there in reuse.


Having our own custom module means not feature bloat - only the functionality we require will be in the product. My issue is that there are plenty of free, open-source project management tools out there with minimal features already. So even if cost is an issue, we could look into open-source. Again it all boils down to the fact that I don't see the point in writing a project management tool in this day and age. It's a bit like writing your own web browser - why?, what's the point?

Although management are asking for this tool, just because they are, it does not mean I'm going to please them and do it just because they asked for it. If something does not make sense, then I will raise it as a concern.

At the end of the day, it's the developers who write the code, it's the developers who make money for a business. Thus, as far I'm concerned, the devs have a very big role in deciding how a company should manage projects and what tools are used. "I am Spartan, argh!" :)

Hmm, I've not been able to make this question a wiki for some reason, thus I'm going to have to pick an answer to accept.


I had a meeting with my boss today. I told about my concerns on us writing a custom tool from scratch. I even showed him OnTime 2010, plus I ran an OnTime SDK example project which showed we could write our own custom code to interact with the data and do whatever we want. I showed all the lists, features, I could think of.

But he wasn't convinced. Un-f@king-believable! :(

So we will have to write everything from scratch, knowing full well that we could just buy a tool of the shelf to do the job. There's a lot of swear words I could use right now to describe how I'm feeling!


Responding to recent comments:

1) A developer who says he "can't be bothered".

There were three devs in the team, including myself. One dev was full time on a client project, myself and the remaining dev were working on a big client project. That means myself and the other dev would have to work on the client project, as well as the custom management module - at the same time.

The end result was that we ended up a management module, written in ASP.NET MVC by a dev with minimal MVC experience (I was only able to provide a small chunk of time to this module, as I was full time on the big client project). It wouldn't be unfair to say it was pretty crap (no fault of the dev). So yeah, I've no shame in saying I couldn't be bothered to split my time writing a pointless management module, whilst trying to also write a system for a client that were actually going to pay us.

2) A developer who doesn't have confidence in his team to build even a simple application to be relatively polished and free of significant bugs (and this is a shop that accepts contract work?

The company did great work, we delivered good software to clients - the devs were capable, as a team, to deliver good work. You've put words in my mouth there. I did have confidence in the team, but I wasn't confident they could build client systems on time, and to quality, whilst being distracted with this custom waste of time.

3) The one everyone picked up on already, dictatorial management.

Our director was pretty set in ways - he wanted the custom module regardless of the fact there were better options. It felt like a lost situation for us. Didn't feel great knowing that he didn't care what alternatives were available.


To put more context on the situation at the time - our boss wanted us to write the client app and the management module at the same time. They also wanted us to actually use the management module (user stories, tasks, etc) whilst it was being built i.e. dog fooding, with tasks related to the client project.

So imagine building TFS, and developing a new version of Visual Studio, but using the in-development TFS to store your work items, user stories, notes, etc relating to the Visual Studio development project. Not cool.

  • 16
    It's amazing to me how often business people have no concept how expensive labor is or what opportunity cost means. – JohnFx Jun 25 '11 at 15:50
  • Take it easy. At least, you won't have to deal with annoying users of the software. – user281377 Jun 29 '11 at 9:52
  • 4
    I know this is a little late, but have you mentioned using an open source project? Since you've got the source, you can customize to your needs, if the basic set up and plugins doesn't do the job. As a demonstration for the boss, check out turnkey linux. They have several different open source project management builds, including trac, mantis, and redmine. He gets the best of both worlds, and if you get one with the right license you can even try to sell plugins/custom builds later. – Spencer Rathbun Mar 15 '12 at 12:57
  • This is a well-known money laundering scheme. 30 years ago it was the Pizza Connection. Now it's the C++ deflation. – ott-- Apr 27 '15 at 21:35
  • 2
    Why not just download one of these -- opensource.com/business/15/1/top-project-management-tools-2015 mess up the UI a little and pretend you wrote it yourself :-) – James Anderson Apr 28 '15 at 11:34

14 Answers 14


Well, I've seen similar efforts before, and in general, they didn't turn out too bad. A custom-made tool comes with exactly the features your company needs, no bloat added. They are more flexible than any off-the-shelf product could ever be.

Sure, it looks like a waste of time, and it probably is, but installing, configuring and getting used to a third-party-tool also takes some time.

My take on the situation: If management wants it, do it. It's their responsibility to decided wether or not it is worth the effort.

|improve this answer|||||
  • Oh, I dunno. Sometimes management are not gods, they need a reality check and it's the job of the people who work there to give it. (And sometimes really cunning management throw out things like this to gauge the people who work for them - they want to see who are the followers and who are the leaders of the future - those being the ones who challenge things that seem silly.) – quickly_now Jun 25 '11 at 10:45
  • 1
    @quicly_now. In that case management needs to be made aware of the actual cost expected for developing this internally. When knowing this it turns into a political decision instead of a technical, and there might be good reason to. – user1249 Jun 25 '11 at 11:08
  • 7
    Totally disagree. Rolling your own takes months to get it right. On the other hand, installing, configuring and getting used to a tool should take an hour or two if the tool is good. I use Pivotal Tracker because I think it's the best. – Michael Durrant Mar 15 '12 at 13:04
  • I completely agree on the last point, but I just can't accept taking the effort needed to deploy something and developing something, putting them on the same timeline and saying they are relatively equal in comparison. That's just a blatant disregard of reality! – Filip Dupanović Mar 15 '12 at 19:47
  • 2
    Michael, Filip: If you have never deployed such a tool, it takes some time to check which are available, which of those best fits your needs. Usually, it also takes some time to customize the tool until it does what you need. They might depend on other things, e.g. MySQL or Tomcat, that you haven't installed yet, because you usually depend on a different software stack. It might take two months to do it right, but maybe a little tool, written in two days, is all you really need in the beginning. – user281377 Mar 15 '12 at 20:19

Ok, maybe I am just paranoid, but this might be a bit of reading the writing on the wall.

Your boss would rather build than buy, are they reluctant to buy other tools and assets? This could be an indication of a cash flow problem. They probably have the cash flow for salaries, but little else.

This might be a time to sharpen that resume up and check around your area for some better run and more solvent companies.

If they don't have a problem with cashflow then:

  1. The boss wants to put a feather in his hat with this project. Telling him it will be a huge FAIL will only make you look like you can't deliver.
  2. The boss doesn't have a f-ing clue about software development, so he is figuring on selling this tool as is to clients.
  3. It is marketing. I worked at a shop where we had an in house tool like this. It took a full time developer to keep it running and add features. Basically $100k in costs / year. But they got to claim and show off this turd to all their clients. (It was a turd, but it was our turd, it worked sort-of).
  4. You boss and management are conviced (incorrectly) that your process is so special and unique no off the shelf tool could work.

Unfortunately any of the 4 above are hopeless causes and again it is indicative of a management team that doesn't get you. Look for someplace that does. It is a sellers market right now and you have the goods.

|improve this answer|||||
  • 1
    +1 for the reality check and the mention of cashflow problems. Every development manager seems to think their product, project, development approach is a unique flower and that an external tool would be vastly inferior because it would require them to slightly bend their process. At my job we reimplemented 90% of the following tools at an extreme (multi-year) cost: SharePoint, Maven, Bugzilla because of very minor disagreeances on how they operated. Duh. – Kevin McCormick Mar 15 '12 at 17:03

If the ROI is favorable, go for it. Otherwise, no.

There are many factors that could influence the decision:

  1. Can you monetize the tool after that? Maybe it can become a product that can be sold..
  2. How is the work going to be influenced by this tool? What happens when the tool breaks?
  3. What happens if all the data is lost because of bugs?
  4. How complex will this tool be?
|improve this answer|||||
  • 1
    3. if you really have to be afraid of that, you shouldn't make software anyway – user281377 Jun 25 '11 at 18:13
  • 1
    @ammoQ if the product really is a commodity that after deployment will see little maintenance scheduled for it, it's still quite relevant. – ZJR Mar 15 '12 at 14:45

Well, this has two sides. All of your arguments are valid. However, the other side is this: Every company does project management a little different. Heck, in bigger companies it varies from department to department. And once you start using a 3rd party tool, there is a strong tendency for the tail to wag the dog. Or, as somebody else put it: if you only have a hammer, then everything starts looking like a nail. You do things they way they need to be done, because that's what the tool dictates.

Once you get into that position, then whatever made your company successful is possibly getting lost, because now you are doing things just like your competitors. And then suddenly the equation looks very different.

Yes, in-house solutions are expensive. But they generally fit like a glove and they differentiate your company from others. And you have full control. Whether you achieve this via a FOSS package with self-written plugins or a complete in-house package doesn't matter. But for a software company, project management is what makes the difference between them and the rest.

|improve this answer|||||

As I read the post, I intuited the correct course of action for myself.

As I finished the post, my intuition was confirmed, along with some other facts.

My thoughts are that you should acknowledge that the intranet will also need rebuilding. This was confirmed, when you said that management have a view to sell the intranet, in the future.

I am interested in Agile, along with UML. From your attitude, I would guess that you are not in favour of UML, or feature-driven development. If you were, it might occur to you that the management view is eminently sensible and achievable, under the right process.

Your attitude towards your bosses is appalling. That line about 'just because they asked for it...'. It's not something that I would put up with although, it doesn't sound as though you are treated as a stakeholder (i.e. somebody that has an interest, or gets an opinion).

I am looking to develop a system to manage an iterative development process. With regard to task management, process management and billing, it's perfectly obvious that a custom tool is required. Your bosses may have the same view, but have failed to share any of it with you.

Why pay for a single feature, that you do not need, that does not reflect your business?

My suggestion:

  • get your bosses to consider that the intranet will require investment, in order to become commercially viable;
  • consider the intranet rebuild as part of the requirement of delivering PM features; then
  • Agile the whole thing, which is what your job; but, above all
  • stop bitching and whining! Your negativity isn't what they pay you for. They are paid to be management, not you.

They steer, you row.

|improve this answer|||||

Unless the bosses are wanting custom features that are not available in a Open Source/ Third Party product I would say that this is a complete waste of time.

Why don't you create a project plan in one of the third party applications to show them how long it would take to design, implement and test this new project management application. Then they can see one in action and understand how many man hours they are wasting.

|improve this answer|||||
  • Even if there are features not available in an existing product, quite a few of the open-source self-hosted solutions offer plugins, extensions, and other add-on capabilities. If there's a particular feature, you can see if anyone else has developed it, and if not, simply develop a plugin. That should save quite a bit of time, since you are only building things that don't exist. – Thomas Owens Jun 25 '11 at 9:33
  • What about implementing the custom features in the third party product instead? – user1249 Jun 25 '11 at 11:09
  • @thorbjorn - That is something I will discuss with my boss. We could supplement the third-party tool with our intranet. Some tools have an SDK that you can use to write custom code to do things like add items, interrogate data, etc. – Jason Evans Jun 25 '11 at 11:59
  • Using a tool or approach that your boss has recommended against to try and "Prove it's worth' is a very confrontational approach. If your boss doesn't like it things will be even worse. I would recommend sitting down for more conversations about the why's with your boss. If he/she is not reasonable now, every week will just get worse for you. Other organizations would welcome your sensibility and pay you well for it (but don't use those words with your boss...). – Michael Durrant Mar 15 '12 at 13:19

Your boss either cares about costs, or answers to someone who does. You need to make your case in terms of hours and dollars. Agree with him on a general ballpark estimate for the hours of work involved, add extra time for bugfixes and support, and multiply it by the normal hourly wage at your company plus overhead costs (for a normal software company, $50-$100 per developer hour is about right for the total).

Now go find an absolutely amazing, top of the line solution, and compare how much it would cost to license it vs to develop your own. Maybe you won't get the top of the line model, but if you start high, you have a lot of room to negotiate down to what you really need.

E.G. Writing the custom tool would take about 800 developer hours (that's 10 developer weeks, or about 5 weeks for 4 devs -- not negligible, but not an enormous project either). Now, multiply that by $75 (our hypothetical total cost per hour per developer, including overhead). This is now a $60,000 project for your company. Now, you find an awesome tool online for $1000/seat, and you have a total of 10 developers at your company. The third-party app is ready now, guaranteed to be stable and fully-supported, and, most importantly to your boss, costs 1/6 of the price of rolling it yourself.

|improve this answer|||||
  • 2
    And the maintenance is generally cheaper than rolling your own. Opportunity costs are a lot lower also. – Tim Williscroft Jun 27 '11 at 23:14

I've used Trac, Trello, Pivotal Tracker and others and I would use Pivotal Tracker.

I would suggest that you talk to your boss again with words similar to:

"I've thought more about this. I really care a lot about this companies future. I really want to see this product succeed. I'm just really nervous that the direction you're recommending will really affect that.

I want the company to succeed and I want us both to succeed.

I feel really strongly about this and I've talked to other folks in the industry and they mostly agree with me. I feel that the direction that you're recommending is not going to help us succeed and I feel so strongly about our company's success that if we take this custom-built route, I'm just going to have to look for other opportunities with other companies.

I really don't want to do this I want to stay with our company and help us succeed but, again, following the right course of action to achieve this is all I want to see.

|improve this answer|||||

This is one of well know management anti-patterns, known as reinventing the wheel. It's typical of big corporations, and driven by Not Invented Here syndrome. Basically managers fear, that 3rd party tool will somehow become unsupported.

Yes, pros of in-house development is having system tailored to your needs, but on the other hand having to re-invent whole basic functionality might lead to not having enough time/resources to actually implement these specifics.

Cons are obvious, not only you have to dedicate your developers' time to creating that solution from scratch, but also to maintaining and supporting it (eg. making compatible with newer versions of external dependencies).

Good solution — take a product that is highly extensible and customizable. Most successful commercial and open-source products are. You can tailor Trac, Redmine, Pivotal Tracker or even JIRA to exactly meet your needs. There are also tons of plugins, so very likely you can get very close to what you need without writing a single line of code.

|improve this answer|||||
  • Thanks for your comments. I agree with what you have said, in that we've wasted a lot of man-hours building this in-house intranet system, and overall it doesn't provide enough value on the project management side. Our superiors think it's a wonderful tool, but considering what we had before (i.e. nothing) then it's hard to beat! – Jason Evans Mar 15 '12 at 18:41
  • I have used quite a few in-house tools in my job, and my experience shows with certainty that such tools have a much bigger chance of being unsupported than commercial ones. – Dmitry Grigoryev Mar 6 '18 at 14:45

Why not take the middle ground and start from something like Trac (http://trac.edgewall.org/) and then customize it? If you got a guy who's good with python then the work could go pretty fast. It's got a nice design which makes it easy to work with. It'd be a good starting point for everything you want to do with lots of work already driving towards your agile development goals and you can give it the in-house love that'll make it your own.

BTW if you've got Perl skills in-house you could start from Request Tracker (http://bestpractical.com/rt/) and get to nice final state too.

|improve this answer|||||

I'm going to answer a little bit different from everybody else so far.

I think it can come down to company culture and/or politics.

As others have stated, the Pros of doing it in-house:

  • Very customized tool for your company's needs
  • Your company builds exactly what they need, no bloatware

And the Cons of doing it in-house:

  • Hard for users to pick up new PM tools
  • Other PM tools may not be fit for your company
  • Higher costs (as you have stated)

I'd like to add that, sometimes, the problem of choosing third party tools is that if that company's tool goes away (bankrupt, abandons project, etc), the company would be stuck with a tool that is no longer supported.

The company culture may not care about any of these things. They may not care to research or try other already available PM tools. An example would be if they are a Microsoft shop, where every software must more or less come from Microsoft. Consideration to anything else isn't given.

Possibly a level of politics could come into play. Some managers want to lead initiatives where they manage a team that builds this, saves the company x amount, etc. Simply using another vendor's tool, won't highlight management's ability to well, manage.

Again, these are only suggestions to possibile scenarios

|improve this answer|||||

Having worked in one place where we replaced the company designed bare bones project management tool with a feature rich, customizable tool. I would have gone back to the reliable, easily supported company developed tool in a heartbeat. The cost to add the few new features we needed when we changed over was far outweighed by the time wasted daily trying to make this tool work for our company (it can take up to half an hour to close a project for instance when it took less than 30 seconds before) and the sheer amount of money it cost as well as the thousands of dollars in customer development we needed to pay for in order to retool this thing so that it was more user friendly.

In general (and this is a personal opinion) I have found that COTS products are usually horrible designs with horrible performance (and as a data person, I've had the opportunity to see a lot of them in "action" and seen how incredibly bad the designs of their databases are) because they try to be all things to all people and do nothing well. And many of them charge too much (we could have paid two developers full time for the price we paid for our useless project management system in that job) and know that their real money comes from paying their developers to come customize for you because no one in your office is going to be able to work their way through all the land mines to do it correctly themselves. Perhaps open source products are better (at least they aren't deliberately designed to make you need their consultants), but I've never worked anywhere where senior management would consider using an open source product for business critical functions.

Perhaps I sound bitter but honestly when 100 percent of the people who use the software daily wanted to get rid of it and the local developers were volunteering to fix the old system for free if we could just have it back, well I have reason to feel bitter about COTS products picked by people who don't have a clue as to what they need but fall for a slick sales pitch.

|improve this answer|||||
  • I appreciate your comments. We have ended up writing our own project management tool and, overall, it's turned out to be rubbish. The advantage is that we can change whatever we want, but quite frankly any COTS would do exactly what we want. Plus many of them have an SDK (which I demo'd to the director) to allow for custom functionality. So anything the COTS did not do we could have filled in the blanks. I think what has let us down is the quality of our project management solution. – Jason Evans Mar 15 '12 at 19:09

Your manager is either playing with other people's money or he has more of his own than he knows what to do with. You did the right thing by informing him of other options and giving insight into the pros and cons, but you are not in a position to make a decision.

Since building your own is inevitable, why don't you take the opportunity to build something that may make your life easier in areas you don't enjoy? There has to be some task that you can automate or integrate with another system.

I'd rather spend 10hrs of comapany time writing an app that did my expense reports than 1 hour writing the report myself. Programming is what I prefer. Obviously, it's not the best use of company time, but that decision is out of you hands. Make the best of it.

|improve this answer|||||
  • In the end we did end up writing our own tool, and it's crap. Management loves it, but considering that there was nothing in place beforehand, it's not difficult to please them. The devs (including me) aren't impressed. When I see things like Axosoft OnTime I just think we've missed a huge opportunity. It's a shame, but that's management for you. Sometimes they insist their way is the best simply because their own the company. Er, yeah, good luck with that logic! – Jason Evans May 8 '12 at 13:07

I heard this sort of fallacy being called IKEA effect, where people put disproportionately large value on things they have build themselves, undervaluing other solutions. Needless to say, this is completely irrational.

I think you did what you could to convince your boss not to do it. You told him about the costs involved, and offered alternative solutions. Unfortunately, the main issue with irrational ideas is that you can't really defeat them with reason.

At the very least, when you will be discussing specifications, try to limit features you'll have to implement to a strict minimum. Ignore the fact that you may be selling the product to customers in the future: chances are, there will be no customers. This way, you will cut the losses, and perhaps end up with a program which has just the features you need.

|improve this answer|||||
  • 1
    Although this incident happened many years ago now, it still annoys me to this day. A dev on our team was given the task to build this "thing", and in the end it turned out to be total rubbish. Not the dev's fault, it was the fault of management. A lot of time and effort would have been saved had we just gone with a third-party product. As a team of just 3 devs, and in the middle of multiple projects for clients, it made zero sense to take one dev out the equation by asking them work on something that was completely pointless. Ah well. – Jason Evans Mar 7 '18 at 8:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.