cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Which is better, People, Process or Technology?

Level 12

The other day we were discussing the fine points of running an IT Organization and the influence of People, Process and Technology on Systems Management and Administration, and someone brought up one of their experiences.   Management was frustrated at how it would take days for snapshots on their storage and virtualization platform was looking to replace their storage platform to solve this problem.  Clearly as this was a technology problem they sought out a solution which would tackle this and address the technology needs of their organization!  Chances are one or more of us have been in this situation before, so they did the proper thing and looked at the solutions!  Vendors were brought in, solutions spec’d, technical requirements were established and features were vetted.  Every vendor was given the hard and fast requirements of “must be able to take snapshots in seconds and present to the operating system to use in a writable fashion”.  Once all of the options were reviewed, confirmed, demo’d and validated they had made a solid solution!

Months followed as they migrated off of their existing storage platform onto this new platform, the light at the end of the tunnel was there, the panacea to all of their problems was in sight! And finally, they were done. Old storage system was decommissioned and the new storage system was put in place.  Management patted themselves on the back and they went about dealing with their next project, first and foremost on that list was the instantiation of a new Dev environment which would be based off of their production SAP data.   This being a pretty reasonable request they proceeded following their standard protocol to get it stood up, snapshots taken and presented.  Several days later their snapshot was presented as requested to the SAP team in order to stand up this Dev landscape.  And management was up in arms!

What exactly went wrong here? Clearly a technology problem had existed for the organization and a technology solution was delivered to act on those requirements.   Yet had they taken a step back for a moment and looked at the problem for it’s cause and not its symptoms they would have noticed that their internal SLAs and processes are really what was at fault, not the choice of technology.  Don’t get me wrong, some technology truly is at fault and a new technology can solve it, but to say that is the answer to every problem would be untrue, and some issues need to be looked at in the big picture.   To give you the true cause of their problem as their original storage platform COULD have met the requirements; was their ticketing process required multiple sign-offs for Change Advisory Board Management, approval and authorization, and the SLAs given to the storage team involved a 48-hour response time.  In this particular scenario the Storage Admins were actually pretty excited to present the snapshot so instead of waiting until the 48th hour to deliver, the provided it within seconds of the ticket making it into their queue.

Does this story sound familiar to you or your organization? Feel free to share some of your own personal experiences where one aspect of People, Process or Technology was blamed for the lack of agility in an organization and how you (hopefully) were able to overcome it?  I’ll do my best to share some other examples, stories and morals over these coming weeks!

I look forward to hearing your stories!

14 Comments
Level 12

This may not meet the particular criteria you wanted, but it is an example of a Process that didn't quite work out the way it was intended. To have better control over changes, Management implemented a "Change Management" process. The would meet every Monday to go over the changes submitted and approved for that week. The problem was that almost all changes were approved before they were reviewed, and in some cases were implemented and closed before the meeting (because as good tech's, we went to work as soon as the change request got an approval!). The result, of course, was unreviewed  but approved changes were being implemented without the review board ever seeing them. Their solution was to add a step that said we could not implement a change until it was reviewed and requested that a status be added to WHD of 'Reviewed'. When we questioned why they didn't just approve the requests during the meeting there was a long silence.....

The entire question and premise is faulty, sorry. "Which is better - People/Process/Technology" is a pretty poor and misleading tagline here. Sorry, something about this writing is either very poor, or just agitates me with the leaps to conclusions that I feel obligated to comment accordingly - this reads like something from buzzfeed or equivalent filler. Dislike. At least the article acknowledges that all three of these are needed, but ugh.

MVP
MVP

Agreed designerfx​, it is a combination of all three as in collaboration.  The given example is when one of the three was flawed and therefore broke down the rest as a unit.

People/Process/Technology are all players on a team...it takes teamwork and proper application of all three to win.  The failure to fully analyze the situation and jump off on a

conclusion which in turn cost the company hundreds of thousands of dollars or even into the millions is a prime example of this.  It could have been a knee jerk reaction at the

management level.  Either way, due diligence was not done to see why the delay existed by stepping through the process.

Level 12

Thank you for your feedback and I completely agree , imagine the frustration of having to live through scenarios like this and that was the intention. To show that while some may feel that one is the end all be all and the panacea to all problems it is in fact a combination.  The very sad part is behind the scenes an extensive people and process analysts had been done and management was informed that a new SAN would not resolve the problem and the process needed to change.

And they still chose to make the decision they did. A lot of good people left following that event, because politics won out over people and process.

I I really appreciate you taking the time to read and respond.

This conversation came up once before. Personally, I am a process junkie. If a task is repeated then there should be a process and it should be measured. But the process is performed by either a person or technology. And if it is technology it is designed by a person. So there is no right answer.

I hear what you're saying - and I get it - but you've asked a question without an answer. The practice of getting technology, people and process aligned is a tough one. Your anecdote sounds more like snark aimed at management than anything (and I understand where you're coming from there, too) - but that isn't really fodder for productive conversation.

Because working with and administering technology is my job, that's the side that I intuitively come from. However, over the last several years in the private sector, I've realized that I (and my entire department) exist to do one thing - to support the business that employs us. That support can mean all sorts of things, though. It can mean having a tough discussion with a business stakeholder, dealing with a poorly-designed application or platform that is simply not going to go away (because the business depends on it), or raising one's voice to be heard in a tense environment to avert data-driven disaster. To me, the 'people' piece of this trinity are composed of two groups - the people inside IT and the ones outside. Both are flawed in different ways.

Technology and process aren't too hard to align in a vacuum, but people are and will remain the wildcard. Will business managers make decisions classified as poor from a technology and process perspective? Yes. Will we as IT professionals make decisions classified as poor from a people (the business) perspective? Yes.

The only solution I see is one of continual improvement, where communication, discovery and definition of business requirements, and a sense of working toward the same goal will ultimately seal the cracks that leak all too often nowadays. We have limited success - but we do improve over time. We don't stop trying, either.

Level 8

My main issue is getting people agree the process on paper so I can research the technology to automate or streamline... Most of the time they look for an easy fix via technology without doing the grunt work first.

People are the answer, even as they can be the source of problem, no matter whether it's HR-kinds of problems, or process, or technology.

In the last century (Hah!  I Love being able to say that in an IT forum!) I worked for an organization that had 30 Novel 3.1 "servers", each unique to a site, each with 8 MB of RAM.  They were incredibly slow, and adding more RAM was required to make them compatible with the next version of OS.

At the time, the technology was deemed to be the cause of everyone's complaints--the OS was clunky, slow, and didn't meet peoples' expectations of needs.

The process to improve their situation became the problem, as budgetary limitation only allowed four sites to get all additional 8 MB of RAM upgrades--all other sites had to make do with 4 MB of upgrades.  No one had bothered to see if 4 MB or 8 MB would fix the problems, nor could they accurately state that the new OS version would fix the problem--an additional and different facet of process failure.

Eventually the garage-brand "servers" were upgraded to 32 MB of RAM, the OS was upgraded, and the output of them was still far from what was needed.  The servers were all junked and the organization looked to Microsoft for a save.

Well, we all know what Microsoft products were like back in the last century.  So it all came full turn back to people being the problem--and the solution.

Level 14

Technology is too often considered to be the "wonder drug"... We've gotten really lazy with respect problem solving... the reason... cost... When disk space, memory and CPU's were expensive, care was taken to make sure that any code was effectively using resources before going to the well. (Think DOS!!!! ) Now, we just add or update.. anything can be solved with more.

People determine the process... the process SHOULD determine the course of action... and sometimes the answer is technology.

cxi​ we all feel for you... we have all been there. The best any of us can do is to learn and try not to repeat...

Level 14

I see people, process, and technology in the same way I look at the CIA triad for network security.  It's all about balance.

Indeed!

  • If you have too many people, you have a waste in resources and an increase in potential security threads due to procrastination (bookface, twitter, pinterest etc etc).
  • If you have overly loborious process it will hamper both people trying to do their jobs, and the integration of new technologies into your stacks (overzelous change control/impossible to approve RFCs due to red tape etc)
  • If you go balls out for the bleeding edge all the time, you'll inevitably run in to skill gaps, bugs (aka "undocumented features") and incompatibilities (you can only lab up so many combinations!).

Keeping the see-saw of corporate IT at the fulcrum point is pivotal ().

Level 14

Loaded question, but I would say the people, then the technology, then the process.  I am sure others would disagree and I expect them too.  I just feel that the people need to build the technology, then the process.  I would say really that it should be people, technology, people, process and then repeat.

Level 12

Very true, though sometimes (I've experienced this in Project Management) the belief that throwing more people or resources at a problem can solve it or get it to be finished faster.

Examples where that are true is, laying sod, digging holes, pulling weeds in the garden.

Examples where that is not true. Copying more files over a constrained pipe will not make the copies go faster. Baking something in the oven at a higher temperature won't always make it bake faster.  Taking more antibiotics all at once instead of over time to try to treat some kind of ailment.

As silverbacksays​ has said, you can experience resource/people waste especially given the scenario.

Level 20

Like they say in CISSP training about security always worry about the people first!

About the Author
Founder at Remedy8 Security, Technology Evangelist, vExpert, EMC Elect, BDA, CISSP, MCT, Cloud, Ninja, Vegan, Father, Cat, Humorist, Author