9 ms·

Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their emp

Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't require mentioning. So here's what you should do. Over the shoulder review of a representative employee of each department. HR, AP, AR etc. Actively watch and understand the processes they go through. FOR AN ENTIRE 8 HOUR SHIFT. No, seriously. Now, you've got a good idea of how its done current. Then do the stake holder interview to find out what they want to do differently. Then plan, develop and deploy your software. I seriously don't get why despite there being a recognized need for understanding the problem scope which everyone one will invest hours in meetings and conference calls talking about, no one actually invests any (significant) time doing, or reviewing the actual process. It's the fastest most efficient way to understand the problem. It would totally diminish months of back and forth "here's what you asked for" "no, that's not what I asked for" development review process that almost _always_ occurs with consultant projects. /rant

TheCapn 15y ago
Say what you will about large corporations but at the very least they can get this right. I'm working for a 4,000+ company now and we take these steps very seriously during our Engineering design. Also part of the job is working with vendors (Oracle, HP, others) who send people on sight from around the world to work with us (the client) and properly interview for the right knowledge. Call me bias, but a lot of smaller companies overlook tried and tested standards. Proper requirement elicitation was documented in IEEE Computer Society SWEBOK prior to 2004 and even that is a summary of important knowledge to Software Engineering profession. Why is it that when a new company comes along with a truly innovative concept they feel they can innovate the rest of the process as well?
roc 15y ago
Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone who directly interacted with the new system loved it. Numerous edge cases that would have been lost in high-level review were caught and integrated from day 1 due to my actually watching people do the job for a day or two per department. The solution has been rock solid (minor maintenance only) for five years. And I almost lost the job. The people who sign the checks were furious. The balance of political power between departments were thrown for a loop. One head in particular treated the thing as a near-existential threat. His entire concept of his job revolved around being the authoritative interface for retrieving and maintaining pieces of data that were no longer exclusively under his control. Another flipped out because middle management saw the results as cause to reduce his headcount and budget, and thus importance. These two departments fought for months, refusing to contribute their shares of budget that were pledged toward modernizing this system. On a technical and practical level, it was the single best experience I've ever had as a consultant. On a personal and economic level, is was one of the worst. It was some of the hardest money I've ever tried to collect. It was some of the most time and energy I've put into the political and 'sales' side of a job (the part I treat as a necessary evil, but very much evil). The corporation has made out like a bandit in the long run. But I paid the price. It's simply too easy and financially rewarding to allow a client's political nonsense to screw up every stage of a project. I have less stress, the people who pay me are happier and I bill far more hours. As with most software, internally developed software included, you don't see better projects more often because the incentives are horribly perverted and stacked against it.
- blader 15y ago
  Wow. Thanks for sharing that. This paints a really clear picture of why so much enterprise software are pieces of crap.
  - angelbob 15y ago
    Now don't overgeneralize... There are lots of other reasons why enterprise software is crap.
- twerth 15y ago
  Well said, and the exact reason I moved away from consulting after a decade of doing it. The developers often get blamed for "not understanding how real people use the system". Most features are requested by C level people who have never actually used the system. While consulting, I've actually been told NOT to talk to the users who will be using the system. In a large enterprise it is often about power and politics, it is rarely about building value and increasing productivity. Vote with your labor, work for a small company.
  - ansgri 15y ago
    For a small consulting company? </sarcasm>
- metaskills 15y ago
  http://www.youtube.com/watch?v=mGS2tKQhdhY http://www.youtube.com/watch?v=mGS2tKQhdhY
- namank 15y ago
  There is process called Contextual Design. Part of it talks about treating the tacit knowledge of a workplace like a very necessary requirement for your software. So that means including the culture of the workplace in your reqs. It sounds dumb at first but it makes perfect sense. What you did at that place was to apply a bandaid to a fracture where it really should have been a cast. But you didn't know it was a fracture because you didn't look past the swelling to the root cause of the pain. This is nothing new, consultants have been loathed for this very reason for a long time now. That was me telling you how to do your job. If you wanna know more, google it. If ya got offended, have a nice day!
grecy 15y ago
This is exactly how we did process review / analysis at my last company. It was always awesome to uncover the differences between what the stake holders thought the current process was, and what the people actually doing it did. After that we tried to reconcile the differences and usually made the in-software process a mixture of the two (where possible)
incongruity 15y ago
You're exactly right – but you realize, there's a whole group of people -- a whole discipline, in fact, that does exactly what you're talking about, right? We're designers. And we do have & run consultancies. Places like IDEO, Frog Design, Adaptive Path, RED, Doblin (Part of the Monitor group now), Gravity Tank, Teague -- and many, many more. User centered design processes should be backed up by rich user stories, that come from real user experiences. The only way to do that is to go out in the field and get exposure to the who, what, when, why and how of what the users are doing, want to do/need to do and how they use your product/service. And if you do it right, you can make a much more successful product that sells a lot better while actually doing some good for the users. Not a bad line of work, IMHO.
gaius 15y ago
This is why corporate software like SAP is so bad. The guy who writes the cheques to the vendor doesn't do timesheets or whatever. His secretary does his expenses and his travel and his holidays. He never touches the software apart from to look at the dashboard and the final generated reports (which will be whizzy). He literally doesn't know it's miserable to use, and unless "subordinates satisfaction with corporate apps" is his bonus metric, literally couldn't give a flying fuck even if he did know.
SatvikBeri 15y ago
Part of why I love my current job is because we focus on the actual users of the software and get feedback from them, not the executives. It made the initial sales much harder, but the results are much stronger and we've gained such a strong reputation that the software almost sells itself.

TheCapn 15y ago

Say what you will about large corporations but at the very least they can get this right. I'm working for a 4,000+ company now and we take these steps very seriously during our Engineering design. Also part of the job is working with vendors (Oracle, HP, others) who send people on sight from around the world to work with us (the client) and properly interview for the right knowledge. Call me bias, but a lot of smaller companies overlook tried and tested standards. Proper requirement elicitation was documented in IEEE Computer Society SWEBOK prior to 2004 and even that is a summary of important knowledge to Software Engineering profession. Why is it that when a new company comes along with a truly innovative concept they feel they can innovate the rest of the process as well?

roc 15y ago

Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone who directly interacted with the new system loved it. Numerous edge cases that would have been lost in high-level review were caught and integrated from day 1 due to my actually watching people do the job for a day or two per department. The solution has been rock solid (minor maintenance only) for five years. And I almost lost the job. The people who sign the checks were furious. The balance of political power between departments were thrown for a loop. One head in particular treated the thing as a near-existential threat. His entire concept of his job revolved around being the authoritative interface for retrieving and maintaining pieces of data that were no longer exclusively under his control. Another flipped out because middle management saw the results as cause to reduce his headcount and budget, and thus importance. These two departments fought for months, refusing to contribute their shares of budget that were pledged toward modernizing this system. On a technical and practical level, it was the single best experience I've ever had as a consultant. On a personal and economic level, is was one of the worst. It was some of the hardest money I've ever tried to collect. It was some of the most time and energy I've put into the political and 'sales' side of a job (the part I treat as a necessary evil, but very much evil). The corporation has made out like a bandit in the long run. But I paid the price. It's simply too easy and financially rewarding to allow a client's political nonsense to screw up every stage of a project. I have less stress, the people who pay me are happier and I bill far more hours. As with most software, internally developed software included, you don't see better projects more often because the incentives are horribly perverted and stacked against it.

blader 15y ago
Wow. Thanks for sharing that. This paints a really clear picture of why so much enterprise software are pieces of crap.
- angelbob 15y ago
  Now don't overgeneralize... There are lots of other reasons why enterprise software is crap.
twerth 15y ago
Well said, and the exact reason I moved away from consulting after a decade of doing it. The developers often get blamed for "not understanding how real people use the system". Most features are requested by C level people who have never actually used the system. While consulting, I've actually been told NOT to talk to the users who will be using the system. In a large enterprise it is often about power and politics, it is rarely about building value and increasing productivity. Vote with your labor, work for a small company.
- ansgri 15y ago
  For a small consulting company? </sarcasm>
metaskills 15y ago
http://www.youtube.com/watch?v=mGS2tKQhdhY http://www.youtube.com/watch?v=mGS2tKQhdhY
namank 15y ago
There is process called Contextual Design. Part of it talks about treating the tacit knowledge of a workplace like a very necessary requirement for your software. So that means including the culture of the workplace in your reqs. It sounds dumb at first but it makes perfect sense. What you did at that place was to apply a bandaid to a fracture where it really should have been a cast. But you didn't know it was a fracture because you didn't look past the swelling to the root cause of the pain. This is nothing new, consultants have been loathed for this very reason for a long time now. That was me telling you how to do your job. If you wanna know more, google it. If ya got offended, have a nice day!

grecy 15y ago

This is exactly how we did process review / analysis at my last company. It was always awesome to uncover the differences between what the stake holders thought the current process was, and what the people actually doing it did. After that we tried to reconcile the differences and usually made the in-software process a mixture of the two (where possible)

incongruity 15y ago

You're exactly right – but you realize, there's a whole group of people -- a whole discipline, in fact, that does exactly what you're talking about, right? We're designers. And we do have & run consultancies. Places like IDEO, Frog Design, Adaptive Path, RED, Doblin (Part of the Monitor group now), Gravity Tank, Teague -- and many, many more. User centered design processes should be backed up by rich user stories, that come from real user experiences. The only way to do that is to go out in the field and get exposure to the who, what, when, why and how of what the users are doing, want to do/need to do and how they use your product/service. And if you do it right, you can make a much more successful product that sells a lot better while actually doing some good for the users. Not a bad line of work, IMHO.

gaius 15y ago

This is why corporate software like SAP is so bad. The guy who writes the cheques to the vendor doesn't do timesheets or whatever. His secretary does his expenses and his travel and his holidays. He never touches the software apart from to look at the dashboard and the final generated reports (which will be whizzy). He literally doesn't know it's miserable to use, and unless "subordinates satisfaction with corporate apps" is his bonus metric, literally couldn't give a flying fuck even if he did know.

SatvikBeri 15y ago

Part of why I love my current job is because we focus on the actual users of the software and get feedback from them, not the executives. It made the initial sales much harder, but the results are much stronger and we've gained such a strong reputation that the software almost sells itself.