Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
My company has been evaluating different crm/project management solutions, hoping to find a solution to our ever increasing workload. I've found some good crm solutions, some good PM solutions, and some good helpdesks, but nothing that integrates well. It seems all the "package deals" that includes all options generally do things rather poorly.
I'm involved in some client sales, a lot of project management, and quite a lot of helpdesk queries. To get an overview of my day I need to keep track of tasks in 3 completely different systems + handle email and calendar. That's tasks/meetings scattered over 5 different places, and I don't feel like I have a good overview of my day. I use a lot of time on just pushing tasks around to make sure I dont forget anything.
What kind of solutions do people use to avoid this? Is there a good "all in one" solution out there that I've missed. Or do people use tools that integrate well with eachother? Or maybe it's my workflow that's the issue.
My team and I have been in the similar situation. We have tested Trello, Asana and many more. In my case I am working with multiple projects in parallel, where every project has different groups of people involved. And, after all the searching, Wrike appeared to be the best option.
I like it as it has a simple and clear dashboard view (with my current and overdue tasks, tasks assigned to others, etc.), Activity Stream and Gantt chart that solved my workload management issue. It also came in very handy for managing our CRM workflow, keeping all our leads and projects in one app. Well, and e-mail integration is my personal favorite (basically, it converts my e-mails into tasks, I just need to add Wrike into the e-mail’s CC and it will be transferred into the app). This, Outlook add-in and couple of more integrations helped us minimize iterations and avoid losing data. Wrike has actually become the “all-in-one” tool we’ve been searching for.
Hope, you’ll find it helpful too. Tell me how it went afterwards.
Microsoft Dynamics Crm 2011 should be able to handle all of this.
It comes with a stack of core functionality which you can then customise and extend to meet your specific requirements. It also have inbuilt integration with Outlook to handle your emails, calendars and tasks.
Client Sales: Mscrm comes with a Sales pipeline, get more information from here and make sure to watch the demo to see how it integrates with Outlook.
Helpdesk: Mscrm comes with a generic 'Customer Service' module, which you can use for helpdesk and support. Info here and demo here.
Project Management: Mscrm does'nt really have anything inbuilt for this, you would need to extend Mscrm for this, that said, Mscrm allows easy customisations (that's not to say it will do everything you want, that's not to say you wont need custom code at times and that's not say its all easy). There's some info here.
Right so that all said, as a little disclaimer: I don't work for Microsoft and I don't get anything out of you buying Mscrm (unless you happen to use my company as an IT consultancy). I also don't know how Mscrm compares to other Crm's out in the market place. However I do know that Mscrm is a very able system.
Hope this helps you to come to an informed decision.
Generally speaking:
Clients don't care about project management other than "where is my stuff?"
Clients will generally pester you through email
Something out-of-the-box is not going to 100% fit what you need (tweaking required)
Unless everything is in ONE TOOL you have no chance of reducing the data silos and the constant "jumping around" that kills productivity
IMHO, you need three projects:
Sales/CRM 'lite' = provides a simple sales pipeline/opportunity management.
Help-desk = incoming email automatically turned in tickets from customers, etc.
Tracking = for managing tasks with workflow so stuff gets done internally.
Simply link items between those three projects so people get a "connected" view of the business. Don't get hung up on Gantt charts but instead focus on managing simple lists of tasks, tickets and the like. That is what needs managing.
You also need an Outlook connector so that:
You can one-click turn a client email into a ticket inside the Help-desk project
You can see in Outlook what is assigned to you
You can see in an Outlook Calendar when items start/finish
You will probably need to find something that you can implement and tune in days not weeks.
Disclaimer: we use the EXACT same model have depicted above: Sales, Help-desk, Tracking. We build a product called Gemini in an attempt to solve this problem hence bias/opinion is inevitable.
Everyone has their favorite PM / Tracker software, and their least favorite, but this one (JIRA) worked well for a very complex and fast-paced dev shop I used to work for:
https://www.atlassian.com/software/jira/whats-new
Things to note
It's primarily a bug tracker, so workflows and issue filtering are
paramount
It can be used as a helpdesk service, through email-to-ticket feature, but requires some (non-coding) fenagling
Medium-sized developer community with many helpful plugins
Can get pricey, cheaper than most CRM solutions though
Lots of reporting features and plugins, including Gantt Agile/SCRUM/waterfall OOTB
setups
Atlassian makes it, and while their documentation and customer service aren't the best around, they're sufficient enough to get the job done when debugging, and it's a big enough company that they can be considered stable (for CYA protection when things go bad).
I personally wrangled a JIRA instance into being a PM system for 50+ projects (internal and client-facing), with 300+ users in 5-15 depts at any given time, with integrated version control features (tickets could be affected via git commit messages), and we also used it to handle inter-office requests (from printer setups to domain purchases).
In some ways we stretched it a little too far (workflows became incredible complex when too many departments had a say in the process), but in some ways we barely scratched the surface of what it could do (it's reporting features are extremely robust).
It's not always the best idea to make one tool do every job, but when push came to shove, JIRA wasn't the worst choice we could have made, and it ended up looking great to front-end/client users. It's probably a little much for a small group to use, but can handle anything from small to extra-large (1000+ users) org's.
[EDIT: forgot to mention, calendar integration (with iCal especially) was not that great when I used it, many events were either in-JIRA or out-of-JIRA (in iCal, gCal, etc) but it may have been improved in the last two years]
Consider RT. I'm a fan, and expect no material gain from this recommendation. Indeed, since the question is OT for SO I expect to lose rep.
I'm currently working with a tool that over the years has evolved naturally from a number of perl scripts accessed through an apache web server, to a huge collection of tools using a common database and web site (still running apache, but using catalyst instead of CGI).
The problem we're having is that different departments have done local branches from the common main branch for implementing their own new functionality and adaptations.
We're now charged with the task of deciding how a common platform can be made available where certain base functionality is made one track instead of having all these different branches.
These kind of problems must spring up all the time so I'm hoping someone have a good strategy to offer as to how we should continue from here. Any thoughts would be appreciated.
In general, make sure you have buy in from everybody involved. Trying to do this kind of project without having people on board will just make your life more difficult.
Look for the quick wins. What functionality, if it changed, would have the fastest and clearest beneficial effect across all departments. If it takes you three months to get some good out of it, people won't rate the good results very highly.
Break functionality down as far as you can. One of the biggest problems in forked legacy systems is that a seemingly innocuous change in one place can have huge ramifications elsewhere because of the assumptions made about state. Isolating state in different features should help you out there.
I was recently asked by a Team Leader (not mine) if I would be willing to undertake a programming project. The members of his team are currently pre-occupied with other more important projects. I graduated college two years ago, and up until now programming has only been a hobby of mine. Recently I decided that I would like to pursue a career in software development. I accepted his offer so that I can gain some real-world experience and start building a portfolio.
In about an hour I'm scheduled to meet with the Team Leader to discuss the details of what he needs. From a short e-mail exchange with him, I know that the base project is to update an existing ASP.NET form—but I also think there's more to it than that.
Considering that I'd like to eventually put this project in a portfolio, what kinds of notes should I take at the meeting?
Take whatever notes you can that will best help you understand the use cases and the user requirements. Everything else is just technical details that can be figured out later.
I graduated college two years ago, and up until now programming has only been a hobby of mine.
In that case, my suggestion is:
revel in your ignorance.
Make the most of the fact that you know nothing and you're being given an opportunity to learn - abuse the chance to ask as many questions as possible of the Team Leader in question regarding what type of questions you should be asking and how you should be documenting what you learn.
You only get one chance to be ignorant, once you've wasted it you have to spend the rest of your life as a know-it-all; take the chance to enjoy the learning process.
Get a list of people who are the intended users. Talking with them will allow you to flesh out the overview that the Team Leader gives you. It is likely that the intended users have a very different understanding of what the app is supposed to do than the TL does. So you'll likely be going back and forth for a while. It's well worth the effort though because you'll do much less re-coding.
Try to understand that the Team Leader him/herself might not even have all the requirements available right at the beginning. Be prepared to be hunting down people and writing all these requirements down as they come in.
Things will change during development, new problems and new requirements will always be popping up.
Three things:
What: What is the software supposed to do, the more detailed you can manage to get the other person to be, the better.
How: Are there any known constraints? For example, if it has to ask for a telephone number, does it have to validate nationally/internationally/not at all. Does it have to run on Windows 2008/2003/all
Who: Two sides:
Who will answer any questions you'll have, will you setup weekly progress meetings?
Who will use the software, can you get their early input on your prototypes, can you ask them for opinion/requirements?
One thing I've found very helpful is carrying a hard-copy of any existing requirements (use cases, wireframes, whatever) or any other potentially useful information in a 3 ring binder to any project meetings I attend. If the meeting strays off topic or questions about previous discussions or documents come up it is very nice to have the information at your fingertips in a format you can make notes on, pass around the table etc.
As a bonus, I find most people don't carry any documents to meetings, so you'll also end up looking like you are a real go-getter who is always prepared, which is never a bad thing.
Main downside to this is that you'll waste paper if the documents are updated and changed frequently.
Find out the where as well, where are the files you need stored on the network, where is the source control repository for the project, etc.
Since this is your first taste of doing a real world project, please please please make sure you use source control even if you are the only dev on the project. Your co-workers will thank you and you will thank you the first time you need to back out a change that didn't work.
We are a small Microsoft shop with 4 developers. We like the idea to have everything integrated and under the same SQL database but not to deal with too many features or a complexity we don't need.
The other option would be to use two distinct third party tools. We also wonder if VS2010 version control and bug/issue tracking capabilities are comparable with the best third party tools on the market.
With TFS 2010, there is a TFS Basic version/configuration options. You can use SQL Server Express as the database, the install is simple and quick and you can install it on a client OS. It includes version system, work items and build system (no sharepoint, reporting...). Price should not be high, the target users for TFS Basic are those used to use SourceSafe. Also if you have MSDN, there is a change that it goes with it, so you would not have to pay extra.
Some thoughts on TFVC in general -- note that I've never used TFVC specifically, but I've been in a similar situation a couple times. My main concern is that it's too little.
TFVC (Team Foundation Version Control) appears to be a client-server version control system. I don't know anybody who hasn't upgraded to DVCS yet. I've never used TFVC but I can't imagine what benefits it'd offer to outweigh the architectural disadvantage. (And before you ask: I only use it from my workstation in the office, where the network has never gone down, but I still use its distributed features every day.)
I also work at a small Microsoft shop with 4 developers and we have never once regretted using Mercurial. It's one of the few decisions we made that everybody seems to have loved. It's one of those moves, like switching to a language with GC, that you never want to even think about reversing.
In terms of support, I hope you found some way to get great support from Microsoft. Things will come up with any VCS and it looks like community support is a couple orders of magnitude worse than Hg or Git.
I can't say much about bug trackers -- I think they're all pretty much the same these days. I've installed a couple open-source ones in an afternoon, even with no experience. The major difference seems to be, if you go with a big-name one, you'll be able to find lots of tools and extensions that work with it. For example, there are a million and one extensions for reporting/testing/etc. for Bugzilla. TFS probably has similar things, for enough money.
Two other things I'd keep in mind:
First, even if you only want these 2 features today, you will want other features in the future, and it will be (sooner or later) something Microsoft doesn't offer. So it's best to make peace with 3rd-party tools ASAP.
Second, unless you miraculously happen to pick the perfect set of tools for your company's future growth for all time, you will at some point want to migrate away from whatever solution you pick today. So make sure it either provides a way to do a full export, or is popular enough that other projects are falling over themselves to write importers for it.
I guess this all sounds kind of negative for TFS. I didn't really mean it that way -- I'm sure it does some things really well. But unless you're rolling in dough already, save your money.
Good luck with whatever you choose!
TFS work ittm tracking is awesome. Whatever your workflow is and the information you want to gather, you can do it easily with TFS.
Most expect TFS to do what they do out of the box as if it were omniscient. Unfortunately, you do things slightly differently than me and I from everyone else. The key is making it easy for the many different roles in your organization to get and input information into whatever your work tracking system is.
There is a plateau you will reach with custom, cobbled together tools that you won't get from cross referencing information along the product development process. TFS removes that barrier. The second barrier is knowing how to consume the information and that takes training and experience in effectively managing projects.
TFS Version control is certainly the low point when compared to the industry right now. DVCS popularity exploded about the time TFS came out. That said, Brian Harry has stated that TFS "fully expect that we will be adding distributed version control to TFS." http://blogs.msdn.com/bharry/archive/2010/01/27/codeplex-now-supports-mercurial.aspx
Take that as you will.
TFS is a great system but after having deployed and used it for some time I realize that the TCO is just too high to justify for a small team.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently a developer at my first job right out of college. I work for a large company, and the trend I notice with them is that they tend to go with more expensive, closed source software about 99% of the time, while there are perfectly good open source alternatives that are available, most of which are vastly superior to their closed-source counterparts. For example, we use this absolutely awful source control software that cost a ton of money, while there are quite a few open source and/or free options that in my experience, albiet limited, are much better and offer basically the exact same functionality.
I guess my question is: How would an experienced developer approach management about using more free software?
It appears there is another question very similar to this that did not show up when I made this one: How can I convince IT that F/OSS software isn't evil?
EDIT: Just come clarification. I'm not necessarily trying to change the company's procedure, I'm looking for advice on how to approach management about the subject.
Start using it in small utilities and things which are throwaway and don't need management buyin. This can prove the worth of an open source solution and put a crack in
the door for using it in other
projects.
Present articles from trade magazines showing that other people are using the open source solution.
Go with products which have commercial support options, such as MySQL, which enterprises seem to have an easier time swallowing.
Pick your battles carefully. Wait until they are suffering. If they are happy with what they have, they will not switch, no matter how much cheaper or superior the alternative is. You need to catch them while they're trying to think of ways to save money, or while they're disgusted with the problems of the current system.
Be very careful with what you refer to as free. There is a very large corpus of products that would be perfectly valid for a student to use without paying that an enterprise would have to pay for. Also never forget Total Cost of Ownership (TCO). A lot of relatively expensive software is expensive because you get things like configuration and help support for them whereas that may not be the case for free software.
I think you are not asking the right question. To me, the challenge is to have my Big Corp to buy the BEST softwares for me, be it free softwares or not.
Paying for Windows or paying for Linux is not important (what is 100 $ for a Big Corp ?).
But having things done better is really important.
I think that your request to your boss should not be : "Hey, it's free and it's as good as XYZ, why are we using XYZ ?"
Why you boss would risk something trying the product you told when XYZ seems to be ok ?
It would be much more better to ask : "Hey, here is what I cannot do with XYZ : (your list). With my product, I would be able to do that and much more so fast than I would have a lot of spare time to test our own software !".
Small money is usually not a show stopper. Being able to work faster in order to do much more testing (or any other things that could help your boss have a better image) is definitely an excellent argument !
Best wishes,
Sylvain.
I work in a big company that has recently moved into being more enthusiastic about open source solutions. There have been a few big hurdles:
Customer won't support it - we're defense contractors. We do almost nothing without customer say-so. As the customer's opinions have changed we've been able to change our architectures and tool usage. That said, there are still scenarios were open source is unacceptable and we don't use it.
No tech support = scary - in several cases, it's been possible to make the point that open source may not have a single point of company tech support, but it does have huge communities that will support questios for free, and that there are consultants available as needed for the really hard stuff. Plus many, many releases of new versions for bug fixes. And, several competing expensive products have not been able to service tech support needs. Being able to point to specific internal examples with long. well documented, histories of support problems, has been key.
Fear of security issues - we had to develop a process for scrutinizing and controlling every peice of open source introduced. We've managed to find criteria for what we deem risky, versus what we deem relatively benign based on info-sec policy.
Fear of lawsuit - Being large, and profitable, we fear lawsuits, we're great targets. We now have a process for the legal team to scrutinize every open source license. This has proved to be a win - since the legal team now has briefings on every major version of the typical open source licenses, and they can quickly review most stuff.
Version control - fear that if those wacky developers can just download anything they like the world will self destruct. OK, well, practically speaking, the concept of "how do we know what's in a given product" - being able to show a FOSS version control process that is managed internally has been important.
It was definitely a slow process - small projects proved profitable and customers started encouraging it in proposals. That made it useful for executive management. It's helped that those that support it have been williing to put in some extra time to making the business case in terms of efficiency/cost savings, and have been willing to negotiate repeatedly with various parts of the corporate infrastructure.
Making open source work has taken the effort of IT, the info security folks, the legal team, the procurement team, and technical management. Knowing that before you talk to your manager is probably a key to success.
There's also some political savy - for a first project, don't encroach on any sacred cows - ie, those projects that may not be successful, but are high profile and owned by someone with lots of political power. Instead, choose some wacky new thing that isn't available right now and prove the cost savings in a way that is unlikely to provoke a defensive reaction.
When you try to introduce open source software to a big company (or even a small one, in many cases), the biggest counter-argument you're going to hear is "There's no tech support." Companies tend to be wary of using software that's supported by the community, because there's no guarantee (or in some cases, service agreement) that questions about the software will be answered within a reasonable time frame, or at all. In many cases, you can find a company that will provide support for the open-source package you want to use (for example, Red Hat does this for its Linux distribution, even though the contents of the distribution is mainly open source). Showing management a business entity that can support the software will often go a long way.
The other counter-argument to using open source software that I've heard the most often is "Open source software is buggy." This is a tough one; this opinion is pretty ingrained in some corporate cultures. Two possible responses are "The open-source community fixes bugs quickly" and "Since we have the source code, our engineers can fix bugs"--but that's often not what managers want to hear.
So, in essence, it depends on the company, their attitudes, and how much they trust you to make business-critical recommendations. I've used all of the arguments above with different levels of success in different companies.
Of course, in these economic times, the "free" part may go a long way. :-)
"Free software" doesn't necessarily mean your company is going to get software for free. Many successful open-source projects are also offered with licenses and services that cost real money and are geared to organizations that want or need to be assured of good support. MySQL is an example
The reason for a lot of big companies using closed software is that they can call support and the vendor will issue a hotfix, patch or cumulative update
Changing a large company's habits are often like turning an Oil tanker around... it takes a long time and uses a lot of energy.
If the company were in the process of evaluating the purchase of new software for a specific task, Then I would make sure to write a concise opinion memo about why my choice is better.
If the software is something I would use personally and not a server product that multiple developers are forced to use, then I would just ask my manager to use it.
If the software is in place, does the job (even if I don't like the way it does it), i'd learn as much as I can about it to give it as much chance of work for me, or at least make my life easier. If it still sucks really bad, I probably wouldn't try to change it until it was time for the company to pay for an upgrade.
If the software works but is just annoying... I'd do as above, learning all there is to know about it just to make my life easier and then deal with it.
You're probably right that the system you'd recommend is better than the one currently in place. But like some other posters said, choose your battles, especially when this is your first job out in the real world. You may become expendable quickly.
It's not really so much a matter of what's better, even if your way IS better, it's a matter of the culture and the way things are done and the cost of switching. Even if, hypothetically, their system can be magically transported to your OSS system, with no loss of data, dates, records, or anything, you're still going to have people who say "I liked the old way better."
Remember: Experience is what you get when you don't get what you want. I know it may sound glamorous to be "the new guy who recommended a great new versioning system that everybody loved", but you also could just as easily become "that hotshot who insisted on a new versioning system that everybody hated." It's a much smarter career move to just play by the rules at least for a little while until you have some clout and can make some recommendations. In the meantime you may even learn why the old system is preferred, or learn to like it more the more you use it.
I know what you mean. It took us years to convince our managers that everything would be okay if we moved away from using Interbase (a commercial Relational DB) to it's opensource counterpart Firebird. Mostly it was fear of no support that blocked the move. I think the factors which changed their mind were:
tests showing better performance
that there are companies that provide and charge for supporting the OS alternative
constant pushing of the argument by passionate developers
I think cost savings would have played a part if our company were paying for the site licenses but in fact our customers were.
I look at this question like this. I work with the .NET framework. I could ask my employer to migrate to PHP. This is a disadvantage to me, as well as my company, for many reasons. Let's start with the obvious.
1.) I know PHP, but can do much more, and a lot faster, with .NET.
2.) Paying for a service, usually ensures a better experience. The Visual Studio IDE is second to NONE when developing an application.
3.) I can develop an application much faster in VS than hard-coding PHP.
4.) This is the most important one. If I work with a big company, I want my programmers to develop my app faster, and I expect it to run faster. PHP (an example Open Source language) is fast, and reliable, but if I can spend the money, I'll deploy ASP.NET.
Basically, big business, or even small business, wants to spend their money, as long as it's for a good reason. Your best bet is to say, 'Hey, if you want to deploy ASP.NET (or whatever), send me for some training. Then I'll be able to develop OUR application to my best ability'.
not to sound totally cynical, but:
an experienced developer probably would not approach management about something like this, unless he/she was already an expert with the open source package. Companies like to have a phone number to call and someone to blame when things don't work. Free open source packages do not provide this kind of 'accountability' (yes we know it's a joke, but management doesn't)
it is unlikely that management is going to listen to someone fresh out of college about any major purchasing or technology decision. You have to learn the business and earn everyone's respect first. [sorry!]
Same problem everywhere. Once an organization gets beyond a certain size (e.g., the Dunbar number) it starts to show a certain woodenheaded quality that will confound you. Lots of history, people, agendas that you aren't aware of. And getting everyone to agree on your solution is difficult.
Best to start locally. See if you can persuade your manager or PM to use SVN or CVS or GIT locally for a project and then get it to diffuse.
But that situation is true where I work as well. I use SVN locally for myself, but a commercial product for integrating with others.
Companies will use whatever will ultimately make them the most money. That means whatever software will make their employees more productive. If there is a particular piece of open source software you think they should use then when the time comes to purchase the software to do job X then as long as you can prove it will make the employees more productive and they are able to get reliable support just a phone call away as with commercial software then they will use it.
Big companies need to hire support staff for stuff like that. When they purchase software from a company, they are guaranteed support with the contract. Open source projects can die off a lot easier, whereas a large software vendor can be held responsible for much greater periods of time.
Every company has a culture, and fighting the culture can be something of an uphill battle. But if you're willing to try:
you'll likely have more luck getting BSD and BSD-like projects approved (MIT license, Apache, Boost, etc.); and it doesn't matter if most of the arguments against GPL and LGPL are mainly FUD
you should refer to the projects as "royalty-free"
you should make sure things are approved by somebody that can approve them (your direct manager) because putting the company in a bind -- especially when you're new -- (even if the "bind" is only in their head) is not conducive to long-term employment
you can probably go a long way by simply asking what the procedure is to choose a library or tool
From a configuration management perspective, having developers add free software stuff willy nilly whenever they feel like is a serious PITA to manage.
I've worked at companies where you were allowed to do it whenever you wanted and others where you could never do it.
There's definitely a balance to be found but if you're in a larger company with multiple projects, you do have to keep in mind that each time you add a new 'tool' it complicates the build process.