True Managerial Intentions - Personal Comments

Post date: Dec 17, 2016 10:09:48 AM

True Managerial Intentions - My thoughts about the post. I guess we've been all there. Purchase, license, use open source, develop totally own software, etc. Let's see what this post says about that and what I do personally think about it.

My Comments

My personal view is that it often seems that building something seemingly simple is easier and cheaper, than buying or even exploring and studying some other project. As bonus we get something which is exactly what we need and not some kind of adapted compromise between our requirements and what the tool / software provides or of the box.

From the reasons why build own the article lists a few:

• Vendor lock-in. - Which is a valid reason in my opinion, especially if the product ties to hefty monthly maintenance or licensing fees. As example, this is one of the main reasons why I don't run projects on Google App Engine right no. You're stuck with Google and even if there's AppScale, it's not 100% out of the box compatible + requires complex setup. That's in the case you'll be requiring high performance production setup. - But if you setup your own 'stack' and platform, then you're stuck with it, just as the article says. - I've been managing multiple projects like that. Only maintenance work being done is panic maintenance when the system crashes and even in that situation minimal work-a-round or horrible kludges are being used, just to make it work. The product reliability is linked with this entry.
• Poor feature prioritization - I wouldn't format it like that. I would say too complex or too many complex features. This will make the tool kind of bloated for our needs. Of course if it about larger project, you could say poor feature prioritization. I work with BI & POS stuff daily, so common problem which I encounter is that ERP provider says they've got POS feature. But basically it's invoicing with option to pay with cash / other payment methods. Which usually leads to bad to very bad usability. Also in Finland the ETFPOS aka credit card terminal integration is very important if you're going to handle any kind of transaction volumes during the day. So for small projects, too complex. For larger projects wrong feature prioritization. If you choose POS system as your primary system, then you're going to naturally lack features full featured ERP system provides. Even if you do get basic, customer management, stock management and invoicing features. - I've seen, and going to see, all of these combinations over and over again. - That's where my integration work is required. - I can agree about the maintenance and support.
• Product reliability - This is hard to comment about. I've seen in-house projects to be extremely unreliable, as well as projects from outside. And of course vise versa. That's why I would simply conclude that this point doesn't make any sense at all. It depends so much from several complex circumstances. It's great that you can fix the stuff when and if required. But truth is that those fixes can also cause extreme side effects. Just what I described with database A B C column stuff a few blog posts ago. These hastily done fixes add a lot of risk something going catastrophically wrong in the long run.
• Meeting product requirements. - That's funny one. I've seen just so many projects where the product / project requirements are totally lost. Nobody knows what the product needs to do or be. I can also say, that's not rare incident, it's actually and unfortunately extremely normal. Yet it offers opportunity to sell consulting and specification services, where we figure out together what's required and how it should be implemented.
  • I were thinking exactly the same, as the article says: "meeting product requirements on schedule and on budget has nothing to do with choosing a vendor vs. building your solution in-house." - But my approach was more like that the talented team of engineers has to do with the decision. The engineers should be focusing on the primary product / business stuff. I've also seen just so many internal projects which some how got started as kind of hobby and a fun thing to do. But when the steam run out of that fun thing to do, the projects got more or less abandoned. - That happens, over and over again. - Also if the project is moved to a new team, they're almost guaranteed to seriously dislike all the decisions and code done done so far. Which again leads to I don't want to do anything, as long as we can claim it's working. Even if it would be working very badly.
• Keeping engineers happy - It seems that at this point I already got talking about the next problem. That's just why they're let to have those kind of hobby projects. Some of those might be also 'unofficial study projects' or something like that.

I really do agree about the stay informed about latest technologies as well as vendors part. Because I've seen something which has been already done, been re-invented extremely badly. Yes, it's 'well engineered' but it's usability is horrible and it doesn't do what the clients would need it to do. After the developer gets direct feedback about the project, they're usually sad / upset. I've spent so much time building this and they say it's no good or totally useless. Well, it is. Why did you spent time on that, when the problem was already solved much better by other product / service, etc.

Final quote from the post: "Stay informed and you will spend your 80% on the 5% that actually matter." - That's just what I wrote with different words, before I did read the finishing of the article.

Just around the topic, from my persona perspective: There are several parallel and independent reasons why saying "building a BI tool" gives me very bad creeps, but I guess I can't go into the details.

Some people claim these things have something to do with software, nope. Absolutely same problems arise when ever doing almost anything which requires customization, change management, planning, scheduling etc. So this has nothing to do with information technology projects or custom software development.

I can also conclude, that my project failure radar is pretty well tuned. I've probably trained my failure prediction model enough. Therefore I can make pretty good predictions how the project is going to fail and which are the danger signs to watch for.

Just to make it absolutely clear, these are my personal comments, and this post has been sitting in backlog for months. I'm not referring to any particular project, client or situation.