I know most of you are reading this blog to follow my story of getting Ataraxis Software off the ground. But I have a day job as an IT manager, and I've recently figured out something about the non-tech side of my company. I'm sharing this with the hope that more tech people will understand the minds of the business people they work with.
I graduated with a M.I.S. degree, which at UCF, is within the College of Business. I took all the standard business classes. Finance, marketing, general management stuff, legal & ethics, economics, international business, etc...
(Side note: I was actually a Finance major for 2 years, then I switched to Marketing for 2 weeks, then finally landed in M.I.S. I kept finding myself reading the technology section of BusinessWeek so I figured I should stop fighting the urge.)
I learned a little bit of programming in High School (Basic, QBasic, Pascal), and a little tiny bit more in College (Visual Basic), and then I became a PHP script-kiddy in my own time during my last year of College. (I mean "script-kiddy" in the worst sense of the phrase. I was the proverbial, kid with a scripting language and knowledge of the SELECT statement.)
I got a job with my current employer in the beginning of 2002 as a web developer in the IT department. I considered myself relatively well-rounded. Business + Technical. I would get into discussions with people at work about how important it was for the IT department to deliver systems that fulfilled what the business needs to do their job. We are their only source of custom software systems, we MUST provide them with the best software we can that allows the business to achieve it's goals. I eventually worked my way to a Project Manager position, and recently was promoted to the Manager of Web Development. (I'm managing a team of about 10 right now. A few Project Management types, and a bunch of developers and designers.)
I've always been very PRO business user. I've always tried my hardest to understand what they need, and work a process to deliver on those needs.
BUT
There was always one thing that I could never, ever, understand about our business users. I see this one thing exhibited more in marketing people than in any other type of business person.
The marketing people know you only have X number of resources. But they want you to be working on X*Y projects AT THE SAME TIME.
You can have a meeting with a marketing person to discuss the current projects you're working on for them, and at the end of the meeting they want to talk to you about the other 2 projects they came up with over the weekend.
Go ahead and discuss these projects with them, and see what happens. :) At the end of that discussion they'll say, "Great! Let's do it! Go! Go! Go!".
As a member of the programming community my brain says, "Dude, these business people are INSANE. They know we're working on a bunch of stuff right now, why would they want to add more to the mix, and have us DO IT ALL AT THE SAME TIME?!?!?!"
I couldn't understand it.
They literally want each programmer to divide their day up into little chunks so everything moves a little each day.
(Side note: If you don't know why programmers shouldn't break up their day into 4,000 little chunks then read these 2 articles: http://www.joelonsoftware.com/articles/fog0000000068.html and http://www.joelonsoftware.com/articles/fog0000000022.html)
There was a project my team had worked on earlier this year, and the end result was something that we actually had to pull out of the system once it was implemented. It just wasn't up to snuff performance wise, so we had to "un-implement" it. In order for us to try to get it working we would need an uncertain amount of time to figure out what was wrong. Possibly even re-code it from scratch. The project had already taken up about about 1.5-2 months of development time.
Shortly after this misstep, I was meeting with the Marketing team that was directly affected by the failed project, and the Marketing Director (who's a great guy) made a comment that I almost missed. He literally said it while he was turning around and walking toward his desk. It was something to effect of....
"You can't just be working on one thing. That's how you fall behind."
At that moment it became crystal clear to me why all the Marketing people I've worked with expect your X number of resources to be working on X*Y number of projects.
Marketing people are hyper-paranoid about not having growth opportunities worked on. Not every idea, and not ever project is going to be a winner that brings in more consumers or more revenue. Tieing up all the tech resources on 1 project is, in their eyes, a death sentence.
It's not just a death sentence for the business. I'm going to go out on a limb and say that most Marketing people are measured by the higher up's in terms of how much money they make the company. So it's their livelihood we're talking about.
With that insight, can you see why they don't want the tech people just working on 1 thing at a time?
It's all obvious stuff when you say it out loud, but you'd be surprised as to how many IT people freak out over these kinds of demands.
So, how do you cope with this situation?
It all come down to management. The IT management has to bend a little, but manage everything carefully so you don't spread your staff so thin that you never deliver anything.
Accept the fact that you are putting the business at risk if you're tieing up all the resources on to few projects, but realize that if it turns into the wild-west of run away projects the business will be in even more trouble.
Here are some tips.
I fully reserve the right to disagree with all this in the future. :)1)
Question the business for justification of projects from a financial perspective.This is a lot easier when the business actually likes and respects you. (Or at least pretends they do. ;) )
Ask them questions! When you enter into a dialogue regarding projects sometimes it makes them realize they haven't fully thought everything out. Try your hardest to not take on projects that don't have a clear benefit, or don't have the potential to make some type of impact on the company. You've only got so many hours in a day!
2)
"Day 1 functionality"Focus the business people on what they need Day 1. I drill this into their heads by repeating it every 3rd sentence. They'll "get it" when you are constantly telling them that you're really excited about the project, but you "want to give them functionality as soon as possible". "We've got to focus on what we can deliver Day 1 so we can get you off the ground. We can always add stuff after launch. What can I give you Day 1 that will make a difference?"
(
Please don't explain Agile or Iterative development to me. :) Those are both specific techniques. This is meant to be a general discussion.)
3)
Prioritize WorkDon't let the business announce 10 projects by waving their hands in the air, saying, "I want these," and walking away. They must tell you in what order the projects are important to them. You must make them realize that regardless of how many you can work on at the same time, you need to understand their priority. And remember, "These 3 are a priority.", is not a priority list. Put the projects in order. 1-10 or 1-100 or 1-X*Y. Get them in order.
A trick I like to use is an "IT suggestion" priority list. It's a starting point. Let the business tweak from there.
4)
Don't get caught up in the small stuff.Not every single problem a user has on a daily basis needs a technology solution. Quickly recognize if building more software is really the answer. Don't let the meaningless stuff reach your developers/designers!
5)
Be very specific about the work you give to your staff. (Oh NO! Micro-management!)After a meeting with the business people is over, sit down with developer/designers and write out the EXACT tasks that need to be worked on. Each task should be assigned to 1 person. Work with that person to figure out when the task will be completed. (There's a lot more to that then I want to go into. Check this article out for more detail: http://www.joelonsoftware.com/articles/fog0000000245.html)
Don't give people ambiguous direction like, "Can you do all that stuff they were talking about? Go ahead and I'll check back with you in a few days."
It doesn't frigg'n work. Some people might actually be able to accomplish something, but every single person I've managed on a project usually doesn't or only achieves 1/10 of what they could have with proper direction.
Now, don't treat your staff like trained monkeys! Involve them in the discussions. Involve them in the scheduling. Listen to them! At the end of the conversation, they should have specific assignments and due dates.
6)
Don't rotate different projects on a daily basis, work your milestones.This is heavily related to #5. Create very specific milestones in projects that a developer/designer can achieve in a week or so. Then you can
consider "switching" gears (projects) upon completion of the milestone. Finishing a milestone that stretched over a few days actually feels good. You "got something done".
7)
Constantly communication with the business regarding status and work load.Have a weekly meeting. Everyone hates meetings, but they aren't bad if you stay focused and keep the meeting short. Just sit down for 20 minutes and update them! No biggie!
When they start bringing up the next 10 projects, constantly re-iterate to them where you are with the existing projects and what level of impact starting new projects will have on the existing ones. Make sure you've got clear direction and your projects are prioritized before allowing your developers/designers to begin working on stuff.
8)
Keep your eye on the prize.Your goal is to get these projects completed. Stay focused on reaching milestones!
You'll eventually get a feeling for how many simultaneous projects your staff can work on, and still launch stuff. If you've gone months without launching something. You've probably taken on too much. Explain to your business people that you've reach your capacity and something has to give. Don't be afraid to talk to your business users!
---
Like this blog post?
Digg it!
