Related
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 5 years ago.
Improve this question
I struggle with finding a good medium on communication. In our jobs, it seems like it's very easy to get lost in code and lose track of time. It also seems kind of ridiculous to send out updates for every tiny task. Even though I am working very hard on getting things done, in a company that has very active communication between other branches, it tends to look bad for me when I'm not constantly updating my status. However, if I'm working on a 3-4 hour project, I'm not going to update management for every single line of code that I output.
Broad I know, depends on the people, company, etc, but what would be a good general rule of thumb for effective communication?
You need to understand why managers need your communication. I have run development teams in the past, and I am currently a coding grunt, so I have seen both sides of the communication.
Managers usually don't have time to be intimately involved in your coding, mainly because they often also have to deal with other coders in your group, testers, senior management, product mangers, customers, human resources, etc.
Your manager has committed to deliver software, and has entrusted you with delivering some of it. Because (s)he does not have time to deal with you, (s)he needs to trust you. (S)he trusts you to focus on your work and deliver the software. If you mess up, (s)he will get hurt too.
The purpose of communication is to demonstrate knowledge of purpuse, to show focus, and to demonstrate results. Here are major forms of communication.
A high-level design communicates that you know what you were entrusted to deliver. It doesn't have to be fancy. I am comfortable with rough sketches of a good data model, detailed key use-cases, and interfaces to 3rd party software.
A development plan shows plausibly that you understand the steps required to deliver. I find that delivering working use-cases is best whether I'm a manager or a coder because it is an unambiguous way to independently verify completion of useful work.
Regular status updates are good because they demonstrate focus. As a manager, I don't care if you have worked on this or that. I care about what you have delivered. From a developer's point of view, a good time to deliver a status report is when you commit code to source code control. Of course, you need good comments to show that you are delivering according to the plan. It is also a natural time to deliver because it represents an end to a "flow" or a period of being "in the zone".
Flagging roadblocks is important because it demonstrates both knowledge of purpose and focus. A good manager will help you resolve these, but (s)he has to know about them.
Dealing with bugs is a particularly sensitive time, because a bug represents a breakdown of trust because, in your manger's mind, you didn't deliver what you said you would. Being extra-communicative here is very important.
Over time, good communication will build up good trust, and ultimately it is the quality and quantity of your work that will determine your trust.
For that 3-4 hour project, you must make status updates when you start it, when you finish it, and on any code-commits you do in the middle (but if you don't, that's fine too).
Agile methodology says you should have 2 week cycles on code development. I think the same is true on communication on big projects. I try to have a major communication every 2 weeks. That includes the status I have on all of my projects and everything. This can be in the form of an email, phone call, or face to face. The only reason to communicate more often than that in my opinion is if you have run into a road block and need your managers help to overcome it or if you are working on a project or task that they need feedback on when completed. In general this keeps unneeded communication to a minimum.
Another approach is to go see your manager directly and ask them what type of communication they want and how often. In general good managers only want updates when there are major issues or on a weekly/monthly interval. You need to discuss with them what is enough to keep them in the loop but not waste your or their time.
This is an interesting question as it high-lights the verbal capacity of a programmer who ends up getting all-consumed in the process of coding that everything else seems "irrelevant", been there, done that with disastrous consequences!
DO NOT BE AFRAID TO SPEAK UP....
If there's something that is bothering you when you code...try talk to them in simplistic terms, ultimately, management do not want to know the intracies of pointer manipulation, TCP/IP stack, control re-freshes upon WM_PAINT, mapping network drive dynamically to obtain some data....you get the drift....
Speak clearly and concisely, be abstract....instead of saying something in wrt to say...pointer manipulation and seg-faulting, just say "There's some issue with the internals of the code that is causing it to misbehave, I'll estimate an n time to remedy this and get it documented and mark the issue resolved asap" where n is a quantity of time, be it minutes/hours/days/weeks or even worse months/years....
If you follow that pattern, that's what management wants to hear, if they hear the proactive approach, that is where you gain rapport and trust, and the level of trust will deepen. There is of course a 'slight hitch' with that...the management might end up piling on a load of trust which equates to responsibility for your coding....be careful there...do not flatter yourself in thinking "Gosh, they like me" at the same time burdening you with "responsibility" of the code....there's a fine balance between communicating and what they want to hear...by the way, I absolutely hate the concept of kissing one's ass in order to get ahead...DON'T!!!!
The moral and bottom line, (my being deaf and finding communication extremely frustrating and made to feel as if I'm put down or not being listened to, it's hard to deal with that because I could easily mis-interpret or mis-understand what's been said, that's my experience of it) speak clearly and do not be afraid to speak out no matter how big or small a coding challenge is or if the challenge is insurmountable and after all, that requires team effort. Share it with the team. I would be wary if nothing is shared and each in the team are in isolation and nothing being said...that's fishy....
Ultimately, lots of communication is good, but if you're in the zone (and believe me, I know how hard it is to come out of the zone once you're in it) find other ways to communicate without losing flow.
Communication can take many forms. If you've got a list of features and can check them off in some way, communication can be as simple as firing off an email for every feature. If you have an issue tracking system, communication can be as simple as updating the issue when you fix/implement it.
To update business stakeholders on your progress? I do this weekly.
To find out from business stakeholders more details about what I need? Several times a week, sometimes several times a day, always either scheduled or impromptu over instant messenger.
To talk to a project manager? As often as it takes to make me more efficient.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Lately I have seen our development team getting dangerously close to the 'second system syndrome' type ideas while we are planning the next version of our product. While I'm all for making improvements and undoing some of the mistakes of our past, I would hate to see us stuck in an endless loop of rewriting and never launching anything.
Is there a good design / development method that lends itself to building a better version 2.0 while avoiding second system scenarios?
I have experience the second system syndrome from both sides as a customer/sponsor and part of a development team.
A root cause for problems is when the team latches on to an Utopian vision of version 2, such as the desire to make the new software "flexible". In this scenario everything is abstracted to the nth degree. For example, instead of data objects that represent real-world entities a generic "item" object is created that can represent anything. One flawed idea is that we can build in so much flexibility into the software to anticipate future needs, that non-programmers will be able to just configure new capabilities. Often one goal such as "flexibility" overshadows the effort to a point that the resulting software doesn't work.
A balanced practical consideration of usability, performance, scalability, features, maintainability, and flexibility goals can bring the team back to earth. "It would be great if..." should be prohibited from the vocabulary of the team. The Scrum backlog is a good tool and the team should be heard saying often... "Let's backlog that...we don't need that for version 2."
"I would hate to see us stuck in an endless loop of rewriting and never launching anything."
Which is why people use Scrum.
Define a backlog of things to build.
Prioritize, so that things which lead to a release are first. Things which should be fixed are second.
Execute sprints to get to the release. Execute a release sprint.
Get someone who has written at least three systems to lead the project.
Try to focus on short delivery cycles, i.e. force yourself to deliver something tangible and useful to the users every few weeks or month. Prioritise the tasks based on their value to the customer. This way you always have a usable, functional application with satisfied users, while under the hood you can refactor the architecture in small steps if you wish (and if you can justify the need for it - that is, towards management / the customers, not just teammates!).
It helps a lot if you have a stable build process with a good suite of automatic (unit / integration) tests.
Agile development methods like Scrum do this, and they are warmly recommended. But of course it is not always easy or even possible to adapt such a method in your team. Even if you can't, you can still take elements of it and apply it to your project's benefit (maybe without even mentioning the words "agile" or "Scrum" publicly ;-)
Make sure you document the requirements as well as possible. While obviously you need to also manage what gets into the requirements to avoid over-designing, having a fixed scope helps prevent developers from running off with ideas or gold-plating what needs to be done and it helps keep management or clients from introducing scope creep. Define all requirements and how scope changes will be addressed.
I'm all for short development cycles (make sure you're writing tests) and agile methodology, but neither of those is a shield against second syndrome system. In some ways it's easier to keep adding on feature after feature if you're working in short sprints without stopping to look at the overall picture. Use agile practices to build the simplest thing that works, then keep adding your other requirements as simply as possible. Remember YAGNI, because when you build a system a second time, that's when you're most likely to build something you're sure you'll need at some point, something that will make the system "extensible" so there never has to be a third build. It's the best of intentions, but the road to hell and all that.
You can't get close to second system syndrome. Either you're in it, or you're away from it. You'll know when you're in it, but only after wasting a lot of resources.
Tips are: know about it (so basically we got that covered already). It's invaluable information to know what a "second system" is, and even more to have some experience with that. I think we all have some experience with that, hopefully benign.
That knowledge will often make you think twice and you'll find a solution without venturing into second-system limbo.
PS: Also know how to use your current system, that includes, maybe documented solutions, and other documentation.
Focusing on the system architecture should help e.g.
Having documented interfaces which support "loose coupling" between sub-systems
Having documented design decisions (avoid re-hashing previously beaten paths)
Hence, without going for an all out swap, the current system can be "upgraded" with more appropriate interfaces to help future growth.
Another good way to focus: assign a $$$ figure to each feature and prioritize accordingly ;-)
Anyhow, just my 2cents
I up-voted S. Lott's answer and would like to add some more suggestions:
Deliver a working product to your customer as frequently as possible. Iterations lasting between a few weeks and 2 months are ideal. Agile methodologies, such as Scrum, lend themselves well to this.
Use FogBugz for feature and bug tracking. Its features are very practical for agile projects. FogBugz allows easy prioritization according to releases and priorities. If your team enters their estimated levels of effort for each task, you can also use this to calculate reasonable ship dates.
Prioritize which features you will develop according to the 80/20 rule (20 percent of the features will be used 80 percent of the time) and the most bang for the buck. This helps keep the system as simple as possible, helps prevent feature bloat, and saves development and testing time.
Give similar thought to both new features and bugs when you determine the priority of an issue. One point of the Joel Test is "Do you fix bugs before writing new code?". In most shops this doesn't happen, but do not make debugging the system an afterthought. Also, keep a working copy of the old system to compare against when bugs are found on the new system.
Also factor in the level of effort required to maintain, and if necessary rewrite, existing code. If you have not already done this, give the team some time to code review whole files that they find troublesome to change. If the system's code was difficult to maintain the first time, this will only get worse and cause your team to spend more time on new features down the road.
It can never be avoided at its entirety. But being cautious could alleviate the problem.
You should formulate some thumb rule based on the vital parameters (scarcest resource) that define the success of the system. For example, reducing potential number of bugs might directly decrease operational cost (potential service calls to support center). But this might not be the case in every other systems. Another example, scarce use of CPU, memory and other resources might be beneficial in some cases but there could be environments where they could be available in abundant.
So simply to avoid "temptations", identify the scarcest resource (time, effort, money$ etc) and consider implementing only those that exceed threshold value.[f(s1,s2...) > threshold]
Despite the iterative development, I would emphasize on how technical debts are handled.
Links that are related to this:
Tech Debts: Effort Vs Time
Tech Debt Quadrant
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.
One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.
From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.
I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.
In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.
Is it possible to have a development process in a place like this?
Would it help to have some sort of management? What kind of?
Is it possible to make quality products with small resources?
How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Maybe there's someone working in a similar shop?
Use Source Control for EVERYTHING
Develop specifications and get signoff before starting - there will be resistance, but explain it's for their own good.
Unit tests! It hurts because you just want to get it done, but this will save you in the long run.
Use bug tracking - Bugzilla or FogBugz if you can afford it.
My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.
If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
Just my though.
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
Have a bug tracking system, both for defects and new features. Don't rely on your memory.
Continuous integration and an automated build can help even a single developer.
Can't emphasize the recommendation for source control enough.
I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.
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 4 years ago.
Improve this question
Do you find that corporate buzzwords or heavy management jargon gets in the way of software project communication? for example using words such as
Mainstreaming
Holistic
Contestability
Synergies
etc.
Would you rather see a initiative within the industry to put a stop to jargon such as this to help people communicate better and keep project communication in plain English? Is it even a problem? What are your thoughts/anecdotes?
I actually like buzzwords, when they are used in moderation.
They became buzzwords for a practical reason: Even though the concepts may be very complex and/or abstract, there is a consensus on the meaning. So with only one word, you can convey a whole lot of information to a large group of people. I see it as a form of encapsulation of information.
(Notice the use of the slightly outdated buzzword encapsulation?)
Of course, that is exactly the reason why many people start to abuse them: They only convey the general concept (i.e. why it's great to do FizzBuzz), and avoid discussing the messy details (i.e. why it won't work).
And since using a buzzword gives the impression that you are deeply familiar with the subject at hand, it can be used to silence others in the discussion.
Conclusion:
Buzzwords are ok - if they are used in the right way. If you want to improve your team communication, train them in the proper use of buzzwords.
I think some kind of industry-wide initiative would be impractical as jargon is in the eye of the beholder.
I think all you can do is make sure that you don't use buzzwords yourself even when communicating with people who do. For example, use the word "people" when talking to a Project Manager who refers to you and your colleagues as "resources".
The use of technical language can both help and hinder project team's progress, depending on appropriateness.
First it's necessary to point out that what is considered "too technical" depends purely on perspective. "Mainstreaming" is as much of a technical term, as SSD, CORBA and SOAP. Something that sounds as jargon nonsense to one person is actually a shortcut to communicate a complex concept for another.
Software development as a rule is cross-domain activity involving in addition to the software knowledge one or more technical user domains. It is a big mistake to assume that sales, marketing, management and banking (just to name a few fields often incorrectly considered "non-technical") haven’t developed and advanced their own complex body of knowledge, in other word — technology: sales technology, marketing technology, management technology and banking technology.
And it’s project manager’s responsibility to facilitate productive communication between representatives of different technical domains. Some suggestions:
Make handy a project dictionary that can be accessed and updated by everyone involved.
Ensure that common denominator language used for cross-domain documentation (i.e. functional specs).
Introduce domain specific terms only when necessary, but then always provide a brief explanation of the meaning (don’t “build from scratch” —leverage the wealth of online encyclopaedias by linking where possible).
Make sure that there is common understanding amongst the project team of the key terms.
Remember that what is considered “technical” depends purely on perspective and you need to facilitate communication in all directions, not just one-way (which is often from software developers to business users).
At the end the software will have to work in the realm of users and you have to make a judgement on how much the UI will rely on specific domain language (this is going to be a trade off between easiness-to-learn and usage-efficiency).
Technical jargon (ORM, TDD etc.) makes one's speech more precise. Corporate buzzwords (aka management jargon), on the other hand, are designed to be able to express vague ideas when full information is not available.
As such, management jargon serves its purpose pretty well, in the sense that it does allow managers to effectively communicate about thins they have very limited understanding of. That said, good manager knows when NOT use the jargon, such as when talking with developers, or with executives, both of whom hate bullshit.
Based on the above, the (Anti-)Buzzword Movement, should rather increase awareness of the proper usage and application of management jargon, and encourage proper information encapsulation only with appropriate auditory.
Personally, I think that the jargon should be used more. I see this occurring more and more and IT people want to simply hide behind the technical elements of the world and act like it is completely the business folks responsibility to speak more geeky.
I'll be honest, speaking more GEEK is not something that the business people can do and you should not want that to occur. Learn the jargon. Become one with the jargon. Own the jargon. Then the next time you are discussing things, you'll not be back pedaling.
Take ownership of the business terms and apply them to the technical side of things...
What's wrong with "holistic" or "synergy"? These are normal plain English words.
Every field has it's own jargon, and that must tell us something - people like having special words, phrases or assigning special meanings to existing words that are only relevant within their own field. I suspect if we went back to the pyramids, there'd be a full set of architectural and building phrases that your average Egyptian just wouldn't understand. So banning jargon just wont work, creating an FAQ and glossary normally do the trick.
BTW This must be a case of pots and kettles. Does anyone outside IT think phrases like - "...We'll use an ORM, and then WCF will talk over HTTPS, throw in a bit of AJAX and some clever CSS on the client and we're laughing ..."
Absolutely. Since managers only talk in general, and we as developers want to understand the precise meaning. I personally fall asleep trying to read abstract writing filled with buzzwords.
The worst being SOA. Neither academic folks nor managers understand it though both use it extensively.
I can't stand buzzwords. One person's "encapsulation" is another's Orwellian destruction of language. Buzwords appeal to the same people who like "decks" rather than memos. For something to act as a representation of many possible things [e.g. "leveraging resources" can mean pretty well anything from using double-sided printing options to drafting people for the Army] there is necessarily going to be a dilution of meaning. If a senior lawyer in my firm were to ask me to "leverage the resources, then run it up the flagpole to get the ducks in line", I'd know that he was tossing back the Johnny Walker at lunch.
Conversely, if I were to respond to a senior partner's memo request with emtpy catch phrases such as those above, I'd be fired on the spot for being an idiot - and rightly so. Too bad the rest of the white collar world isn't like that.
Grouchy Old-fashioned Gen X'r
I'm OK with buzzwords so long as all the stakeholders (see what I did there?) are clear on the shared meaning of each word/phrase.
In general I think that buzzwords are good when used for encapsulating ideas and concepts. it simplifies communication between people who understand the words. However, I draw the line when people use a buzzword when a perfectly normal word would do. I know someone that will say they were "On an Audio" when they mean phone calls or say "dialogging" instead of talking. It makes me want to hit them. Hard!
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 9 years ago.
Improve this question
What would be the disadvantages (if any) of automating business process for a Enterprise/organization?
Loosing discretionary error checking, i.e. numbers that look out of line;
Potentially, knowledge of how a process is operated could be lost if it is automated but not documented. More often than not, manual processes are passed on;
Accountability for the process becomes muddled.
You lose some flexibility on unplanned situations. On a manual process, you can often "work around" the process when there is something you did not expect, but with automated processes, you cannot.
The money you need to spend to automate it.
Would depend upon the process, but the classic situation where automation fails is when the automated system decides badly or masks a problem.
Another might be where it becomes a maintenance issue. Humans adapt pretty well to fluctuations in the process flow, typically automated systems don't.
Again, its a fairly vague question so it is hard for me to talk specifics. Do you have a particular process you want to automate?
It's always difficult to find a right tool for it.
You may end up ordering a custom tool and it's risky. However an off-the-shelf tool might be as difficult to implement.
It's very difficult to capture the business process right. Sometimes it's quite convoluted - especially in a big and old organisation. You may end up having 80% of cases automated and the other 20% being impossible to do at all
It's an investment for which a ROI should be calculated carefully. Sometimes you are better off just not doing anything at all.
Saying that I was involved in the projects where the automation of the business process allowed 1 person to do the work of a small department and that department was able to spend their time on significantly increasing the company revenue
Automation is set of tools and procedures to make things work more effectively,
but there might be problems:
If user support is automatic (and non-relevant), customers might start to feel that you don't care about them. Some people want personal support instead of automated replies.
If there are problems that are not covered by set of features in the system and data gets missing because of it.
If there isn't anyone to check frequently that system is still working in right way.
If automated system haven't been tested enough and errors cause big losses (financially or in reputation).
If something else goes wrong (and there isn't anyone to fix it).
Make sure that you have enough people to maintain and support your system so if automation fails, your business wouldn't fail with it. There are many examples of failures in automation of business processes so plan your projects well before attempting to do things. Think of possible (and impossible) ways of how automation might fail and make enough of error checking to make sure that things go right way even in case of errors (in input data, processing of information or at some another level of system).
Sometimes it is better to do things manually while in other situations automation is way to go.
Automating a business process just for the sake of automation is a fools errand. And is likely to cost your business A LOT (in every way you can imagine - financial impact, business disruption, new technical issues, morale, etc...).
Without care, automating a business process can:
cost lots of money (without necessarilly the possibility of making it back somehow)
take a long time to implement (use of resources that would be better used elsewhere)
make the proces more brittle (loss of flexibility / adaptibility)
uncover issues with the current process that are minor and blow them out of proportion
create errors if something in the process is overlooked
demoralize your staff
Based on my experience, assuming the business process has been design well and implemented correctly, here are the disadvantages with BPM automated business processes:
Changes to the business process will required changes to the BPM solution.
Making changes to the business process is harder because you have historical data that you need to migrate or it forces you to use a sub-optimal work around instead.
The business process can be affected by the maintenance of the BPM platform.
The business process can be lost in the system due to BPM engine error requiring developer support.
The costs?
Loss of staff -automation can work so well that you will need fewer workers.
Loss of poor quality output - automation can provide berg predictable results.
Lack of 9-5 work - automation software Dan run anytime you set it to. I have built routines that run every three hours and have been running for years.
Loss of unhappy customers - quality and benefits go up when automation is done correctly. I created an automated Email routine that alerted our employees exactly the amount of money we placed in their bank account on pay day. This was easy to do since I had just automated the creation of the text file needed to upload to our back to pay them already had the needed numbers.
You get the idea. Automation done right costs lots up front..... but pays for itself in savings and increased benefit over a short amount of time!