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.
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.
My favorite thing like this for a purely technical topic was a project where there was a mandatory requirement to NOT support ethernet auto-negotiation.
Why? The company had a long-standing policy of manually setting speed and duplex to ensure that there were no duplex mismatches. The was a team of 6-7 people who would audit servers and check switchports, and they produced a report was issued every week, and reviewed by the CIO and other luminaries. People would be shamed for errant configurations, as only the auto-negotiation team could configure NICs.
The director who controlled the auto-negotiate squad was politically powerful, and got all sorts of power out of it -- including banning GigE. As late as 2010, this org was deploying dozens of 100MB NICs to ESX hosts to get sufficient bandwidth. They also purchased 100MB NICs for desktops.
I don't know if you were around 10 years ago, but there used to be real problems between certain network cards and switches that prevented autoneg from being 100% reliable. For any company of a certain age I would not be surprised to see a policy like the one you describe.
The surprising thing isn't the policy. The surprising thing is the persistence of the policy even after it's no longer beneficial in any way. It's been more than a decade since Ethernet auto-negotiation became reliable. During that decade, that company has paid for a team to go around and do manually what could have been done by an automated process for a trillionth of the cost. That's a staggering amount of waste.
The policy has to be proven to no longer be beneficial, and I'm pretty sure every major OS has had a way to remotely set the card to a fixed configuration or autoneg since around then, but that's a separate issue.
Thats why policies, like contracts, should never be evergreen. Policies simply amount to internal contracts and any company that does not regularly review and refresh them is doomed to this kind of waste.
like the parent or evergreen? No I have never worked anywhere that promoted such abject waste through "adherence to policy" but I likely would not have chosen to work at such a place to begin with.
Absolutely... IIRC, the IEEE standard was ambiguous, and each vendor implemented things differently. I think the standard was "fixed" in 1999... This situation happened in 2009!
But the technical problem wasn't the problem -- the issue was that they created an inquisition that had outlived its purpose.
For a long time that was my first question anytime there was a network problem that wasn't a simple solve on the client.
Step 1: Disable/Enable interface
Step 2: Call NOC: "Can you tell me what this port is autonegotiated to?"
And horseless carriages used to be less reliable than horses. The problem is the longstanding nature of the policy. They were paying a team of 6+ techs, surely they could afford a process-review/technical updating meeting once a year? And surely there's a better way, such as standardizing on a brand of NICs and of switches, and being done with it. If you can't push an update to the machines to prevent this anyways.
Besides, it shouldn't cause cascading failure so the worst case scenario is a tech call, the same as for an unplugged cable.
Several comments here indicate that this practice is outdated. I disagree strongly. Even in 2011 autoneg is flaky on many switches - in a recent shipment of ~100 machines, ~5 of them autonegotiated to 100mbit instead of gigabit. And these are name-brand machines with name-brand switches.
Forcing duplex and speed with ethtool is still relevant.
Great anecdote that illustrates this principle observed by Upton Sinclair:
"It is difficult to get a man to understand something when his salary depends on his not understanding it." (from I, Candidate for Governor: And How I Got Licked)
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.
For these political reasons, it's important to have executive-level support, or else it would never fly. My first job out of school was doing exactly as the gp suggests at a national telecom. Job-shadowing people in their day-to-day work, understanding their problems, and turning around web/desktop apps within days or weeks to solve their problems. We had huge success. We won an international award for what it's worth (Stevie Awards for Best Support Team). We saved our company millions, and were one of the keys for the company to survive a big labour dispute. Can you believe that previously, for a national telecom, all orders for corporate telecom solutions had to be gateway-checked by a single person? We democratized stuff like that so that processes could be much more flat. No need for requirements documents, no change control, complete freedom of creativity, complete freedom to decide what work to accept, etc. I know how that's sometimes necessary for big projects, but for small high-ROI stuff, it was beautiful.
The other side of the story is that we ran into huge political problems. Every day, someone was trying to kill our team because we were making the traditional IT groups look bad with our turnaround time and solutions that worked. On the other side, we were automating things that people didn't want automated. If we didn't have support from the CEO down through a specific chain of command, we would have been killed within months, if not weeks. We didn't even call ourselves developers. Our official position title was business analyst because then IT would bug us less. We weren't even part of the official IT department because those guys couldn't get outside the box. So we were just a small group of business analysts who tried to hide until we were too successful to hide anymore. That's when the attacks really started coming. And then we continued to be successful, and then they started trying to copy us instead. Last I heard, that team's unfortunately been swallowed up by the bureaucracy now, and is a shadow of what it once was.
Having consulted with various branches of the US Govt for about 13 years, I can safely say that this is almost exactly how most govt projects work. They are far more often about satisfying political objectives for bureaucrats than helping the user.
This is why I'm far happier now consulting to startups than to large corporations or the govt.
From my experience in consulting (over a decade), I have to agree. It's extremely difficult to convince people to do things right. It's sooo much easier to give a friendly grin, a firm handshake, maybe dinner or a round of golf and state emphatically that "you need an ERP or CRM or other three-letter acronym".
Ultimately, it comes to corporate Darwinism... the companies that evolve reasonable processes prevail. Others will only leave a fossil record. Unfortunately, we have governments as well as corporations.
>> 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.
This is now one of my favorite comments from this site. Very well put!
I have less stress. But have I done my client a service? No! I've helped enable the flawed behavior that led them to engage me in the first place!
Are you a consultant because you want to earn a big paycheck without much stress or because you want to make teams better? For me, the latter comes first.
I even go so far as to tell the client when I believe that I can no longer add value equivalent to my cost: when they no longer need me. My job is, ultimately, to become superfluous: to make them better then get out of the way.
Now if I was engaged because of that delusional thinking, that's another problem...
Oh God. I sympathise I really do. I have been in that particular situation twice and never again. I am very wary about internal politics in certain types of organisation and like to have a full overview of it way before commiting myself. If that's not possible I don't take the work.
I admit to liking waterfall myself (it suits the kind of work I do) and if well done by competent people and for certain types of project its the way to go ...
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!
Personally, I see a very clear line between culture and politics. The people of the various departments didn't have any conflicts. It was strictly between department-heads.
And, for what it's worth, the C-level types loved the project too. What I did was replace a wooden peg with a modern prosthetic and upset the guy who was selling wood oil for conditioning the peg and the guy who sold the leather straps [1].
edit: That said, sure, it'd have been less stressful if I worked in the politics up-front. I said as much. But I've done it that way enough to know it would inevitably have compromised the system. And my post was a response to "why aren't the systems better?".
[1] and him, only because he couldn't see past the loss of the peg-strap business to see the gain of business making, maintaining and adjusting straps for the modern prosthetic.
Seems to me the C-level execs should have given you more cover. It's their job to manage their organization, not yours. This strikes me as a failure of leadership on their part.
Sure. But have you ever found a large company that paid any of their bills on time? Particularly after they have the deliverable, their incentive is very much to allow their middle managers to continue inventing 'concerns' and delay payment.
Everything was couched in "We're really happy. We're not sure why Bob isn't. But we'd really like you work with him to sort that out."
You are right, there IS a line between culture and politics.
But thats the thing. You should count politics as part of your requirements too, or thats what the theory states anyway.
For example, lets say you digitized an inventory form for a sales dept of a plastic company. By doing this, you effectively removed use of a pen from the 'system'. Now what politics could you possibly be affecting by eliminating use of a pen? Well, you could cause an uproar between the finance dept and the sales dept. Finance says that the organization's major stock holder is a pen company and the sales department must use pens (for whatever reason...lets pick advertising and promotion).
Now your system made the world efficient but it failed to account the current work practices of your client. You, sir, just screwed up.
Sounds a bit like the guy who had some really good advice to give, but didn't take into account the politics and context of the forum he was posting to, tagged it with a douchey comment at the end, and got downvoted and ignored.
I agree with the sentiment, but how can you know to trust someone's advice if they're acting in a way that's obviously very socially stupid? (I'm not huge on excessive politeness, but I think it's quite stupid to be aggressive for no reason. What purpose does that serve? Why should I trust the advice of a person that acts that way?)
It feeds into teaching me about people...I'm currently trying figure out how to work with really smart people and how to build and sustain high performance teams.
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.
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?
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.
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.
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)
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