Confessions of a Corporate Drone

Maybe, but what she’s describing is borderline incompetence. A business rule is something along the lines of a statement that defines the way the business does something, and a test case is something almost entirely different.

I see where she’s coming from, but I think maybe she’s overestimating people’s internal motivations, which is not at all an uncommon problem. I mean, I keep hearing people say that you have to have passion for what you do. And some of them really seem to get up in the morning and have their SpongeBob moment and say “I WANT to test code today.” and walk out the door whistling a happy tune.

Most people don’t. Their jobs are the way they get paid, and through that, enable themselves to do some combination of what they want and provide for their families. They don’t actually ***care ***about what’s getting done- in a year’s time, they will have worked several other projects to completion after the current one. And in a year or two past that, it’s likely they’ll be doing something to replace what they’re putting in today. And unless there’s a good and prompt reward/punishment scheme in place to keep them on track, they’re liable to be only as motivated, hard working and conscientious as necessary to get the job done adequately. Doing a better job actively loses them time and effort, and gains them stress, with no positive results.

Some people don’t work like this- they’re the ones whose internal motivation is centered around doing a good job and being good at what they do. Most people aren’t. Many IT folks are more motivated by the challenge of solving the problem, and lose focus and motivation once that’s done. Some are interested in the learning aspects and couldn’t personally care less if a project works well or not. Some are motivated by status, and working on important, but low status or low visibillity projects is not motivating to them.

Companies try to get everyone on the same page with all sorts of rah-rah corporate culture stuff and slogans and what- not, but for the most part, it’s BS. \

What I have noticed is that upper management tends to have very fixed ideas of how things should work, and when confronted with underlings who think outside the box, they don’t give it adequate consideration because they’re too busy looking in the box and not understanding what this guy is talking about. I seem to be the poster child for this- we’ll have problems, I’ll suggest a solution, be told it’s not feasible, or looked at like I’m insane. Then a few years later, we’ll have a regime change of some sort, or someone will read a magazine article, and suddenly we’ll do exactly what I suggested years earlier. It’s frustrating to an extreme, but considering this has literally happened everywhere I’ve ever worked, I’m resigned to it.

What does frustrate me are coworkers who have zero initiative. I don’t mean in terms of volunteering, or taking charge, or anything like that. I mean the ones who just won’t even dig in and figure out things to do their own jobs adequately and expect everything to be served up on a platter and spoon-fed. I’m a BA just like JCWoman, and we have developers who pull this crap all the time. A requirement may not be 100% clear, or there’s some technical design that needs to be done that’s out of scope of the BA’s role or knowledge, and they’ll basically sit on their hands, claim the requirements were unclear, or that they don’t know what environment to use, or whatever. Never mind that they didn’t ask a single question, or try anything out, or put out any effort whatsoever to try and remedy the situation. Nope- they’ll just blame someone else.

This is one of my least favorite parts of being managed.

“You have ten tasks. The deadline is in two weeks. Therefore each task will take one day.” sigh

Last Friday I got an email from the person running the project management software for my team asking why I wasn’t done with my tasks. I had given the estimates for five different tasks, with coding time ranging from 4 to 16 hours apiece. Added to that was 40 hours for unit testing, before we turn it over to offshore for system and QA testing. He had scheduled the start and end dates for each task correctly, such that I was supposed to start one thing after I finished the last. But he set the unit testing start date to be the same as the start date for the first task. So I was burning thru two sets of allocated hours at the same time. So I was late.

Fortunately, it didn’t matter. For two reasons -
[ul][li]The system that is supposed to feed me test data isn’t even started, so I have been faking my own test data. I had a meeting with the woman who is going to code that system, so I could explain to her what I expected. This is because of the second reason, which is[/ul][/li][ul][li]The specs document was scheduled to be delivered the day coding on my **second **task was supposed to start. And it is not ready yet.[/ul]But I am keeping my mouth shut. The last time I complained about starting coding before I had specs, I got assigned to meet with the users and write the specs document. And when I set up the first meetings, they had never heard of the project. [/li]
Regards,
Shodan

Yes, exactly, but think of this situation with much larger projects. Like the current one I’m assigned to. They picked a delivery date, published it to external customers and then decided to rewrite the software from the ground up. We’re rewriting it onto a new architectural platform, new database, all new UI technology and adding some features. Our company is trying to learn how to be Agile instead of doing waterfall projects, so what they did was make this a series of small waterfalls but are calling it Agile. The business analysts on the team (including me) are new but that’s okay because they clearly didn’t scope out the “sprints” based on any kind of labor effort on the business side. I can’t figure out if they thought one BA could handle it or planned to have 5 (we have 2.5). We’re falling very behind on getting requirements finished in time for the dev team to code, and each sprint we’re getting further and further behind. I’m frustrated enough with it now that I’m like cest le vie! I guess the only way to learn better processes, like project management is if you get your collective asses handed to you by your external customers.

[quote=“Shodan, post:22, topic:762559”]

[ul][li]The specs document was scheduled to be delivered the day coding on my **second **task was supposed to start. And it is not ready yet.[/ul]But I am keeping my mouth shut. The last time I complained about starting coding before I had specs, I got assigned to meet with the users and write the specs document. And when I set up the first meetings, they had never heard of the project. [/li][/QUOTE]

LOL, it sounds like you work with me! On a serious note, remember way back in the middle of my screed I mentioned in passing that we managed to compile a few hundred test cases before we knew the business rules? That happened because our dev team knows their shit and the business team (mine) don’t. Well, let me clarify. Our BA lead knows the business rules but he seems to be assuming that the rest of us do, when the rest of us are new to the company and don’t. He also seems comfortable with the idea of just letting us waste time guessing what the business rules are, documenting them and then having the dev team tear it all up and rewrite it in review sessions. Some lead. He’s setting his own project up for failure because see above in combination with letting the dev team drive the business requirements.

Every single company I’ve worked for had quality managers, departments, manuals created and managed by QM… I can remember one where the quality manager was a horrid bitch, and I’ve also seen a few cases where the focus was too centered on dots and crosses, not enough on content, but in general it’s a good thing to have. Even when they’re centered on dots and crosses, at least they force people to have documentation.

My current employer has a whole bunch of people to do QM on code, they have one of those systems where you give it the processes with cases for each step and the system generates test scenarios, tracks which cases have been tested already, etc. I worked with one of those once and it was a bitch to set up, but once you had, it saved a metric asston of work.

I suspect this may be the result of your career position. Specifically, you’re a “cost” in their system versus a revenue generator. The same would apply to any sort of cost position, administrative and other support. But when looking at revenue generators, that would not apply.

So for example, if a law firm was looking to hire or promote a lawyer, they would definitely be looking for a “rock star” type, who will bring in the big bucks, rather than some drone going through the motions.

But she’s not support, she’s production.

I’m not sure how “production” falls on that scale. If her product is being sold to outside clients, then she’s a revenue generator. If it’s supporting others who are selling, then she’s not. (She mentioned government in the OP, so I assumed she was support, but possibly she’s been in different roles.)

Yup … I escaped by starting my own business … where hard work and deeply caring was abundantly rewarded … [ka’ching] … maybe not an option for everyone though.

Agree with F-P.

Nobody really cares about improving the process of developing software for internal corporate consumption. When VP’s get tired of hearing complaints about it from other VP’s, they simply re-organize and give the oversight function to some other mid level director or manager, for a while.

I’ve been on both sides in different companies. In some I’ve been on the IT team that was a cost center, in other companies I’ve been on an IT team that was a revenue generator. Not much difference other than how much shit we had to eat.

Here’s an interesting example of how being on the revenue side may not help. You often hear advice to put actual metrics/numbers in your resume showing how YOU had a positive impact on a company, right? For example, increased Sales by X%. That’s usually hard for IT people to do, but I was able to do it once. I identified an opportunity for my group to sell a new maintenance contract “product”. With my boss’s encouragement, I actually worked up the ROI and cost justification and wrote a business proposal that he then pushed through the management chain. My math said it would bring in $15,000/customer/year in additional revenue. It required the work of one software engineer (me) to fulfill for all of the customers it was sold to. Basically instead of letting the software languish and then engaging in costly fire-fighting (labor but also customer relations), I would pro-actively keep the software updated and rolled out to the customers who bought it. (Because, yes, our normal way of doing business was to install it and walk away until the customers called to bitch us out.)

I was befuddled when, after our accounting folks set up the accounts for it so we could sell it, nobody ever bothered to sell it. I couldn’t understand how an easy revenue generator would be snubbed. It took me a few years to realize the reason for it. It was unfortunately at the major fortune-100 corporation where this happened. Meaning that my piddly little revenue wasn’t even big enough to nudge the round-off margin of error on the annual statements … that were expressed in the billions.

Losing your naivety is as painful as losing your virginity sometimes.

Exactly. First decide how long X will take, then decide what X is, is not a recipe for success.

That approach of creating the test cases can work. One of the project leads I most respected always began a project by designing the test cases before creating the project plan or setting the deadlines. But the documentation of each test case always - ALWAYS, he was obsessive about this - included a link to the business rule it was testing. That way, we could always go back to the users and get them to say “oh yeah, that is from the old system - it should do X, except on alternate Thursdays in months with no R, when it should disallow X and instead do Y.” Add it to the test cases, document the business rule, and at least the coders know the target they are shooting for.

Remember that I said I was getting shit from the project tracker, because I wasn’t done with my tasks? He moved the end date for unit testing out, although he only allocated half the number of hours I estimated, because it coincided with the start date of somebody else’s task of feeding me the test data. But then he asked why I had not started my next task, but instead moved it to the “To Do” list on the project tracking database tool.

Me: “I did that because the project tracking software was apparently coded by someone who had never worked in IT - it only allows you to say you are working on one thing at a time. I was assigned a defect from the previous release which is my top priority - it is stopping offshore from testing.* I am working on that.”

The Project Tracking Guy: “Did you set up a task to show what you are working on?”

Me: “I tried, but I am not authorized to set up tasks that will impact other people’s deadlines, and the generic defect resolution task is assigned to the offshore team and I am not a member of that team. So I can’t show that I am working on the defect. The defect is documented in this other system that does defect tracking.”

TPTG: “But the defect tracking system isn’t tied into the project management system. It will mess up the deadlines if I add it.”

(Me, trying to hold back my tears): “Tell you what. Why don’t you update the unit testing task to include unit testing of the defect I am fixing. I will be unit testing the fix, so that will be true.”

TPTG: “Good idea!”

Moral of the story: It doesn’t matter what you are doing. It only matters what shows up on the exception reports from the project planning system.

Not that it matters. I have analyzed the defect and have a fix ready. I talked to the very nice lady who is supposed to write the system to feed me the test data, and she is not even started, because - surprise! - she is fixing other defects. So I can happily mark my unit testing task Done on the deadline, and everyone is happy.

Regards,
Shodan
*Offshore, when they hit a failed test case, just sort of stop and don’t do anything more. The boss of my boss’s boss would be puling his hair out over this, if he had any hair.

Reading you both I’m wondering if that’s where the “documentation” in my current project comes from.

I’m used to having/creating:

  1. lists of requirements
  2. process definitions
  3. specs for any programming needed (exception: there is a “loads for dummies” screen, programs created via that screen don’t get a spec)
  4. manuals
  5. test cases (one of the things that’s tested is the manual)

But here all we’re getting is 3 and 5. I… miss… my process floooooooooows! :frowning:

Here in the education-industrial complex we deal with a zeal for ASSessment that is essentially busy work of the highest order. Admin critters, being admin critters, love to toss around corporate buzzwords and ideas that don’t really apply to higher ed and their Tools of Toolery are assessment.

We assess this course curriculum and outcome. Then that course’s, then that other course’s . . . ad infinitum and nauseum.

The outcome? The college pays three full-time assessment experts and absolutely nothing happens. Ever. Oh, except at least a few profs I know manipulate course outcomes in to avoid having their course outcome assessments re-assessed and then those re-assessments re- re-assessed.

Sigh

Absolutely, the test cases are fantastic. My issue is that they’re so complex and so voluminous that I and my mentee quickly lost sight of the business rules that they should reference. We started out months ago trying to suss out the business rules in meetings with the developers. They sort of took over the meetings and took over the documentation of each scenario - for a while I tried keeping notes in each meeting but they went so fast that it wasn’t long before I was sitting there wondering what was actually going on. I didn’t have the experience with the company’s data/products to be able to tell them if they were off-base or correct. So they pretty much ran us over and left us in the dust.

At the time these meetings were going on, I told our BA lead that we weren’t getting anything out of them and unable to follow what was going on. He just told us to keep going because we needed to understand it. I don’t think he realized we were literally NOT understanding it. The developers were “mowing the lawn with nail clippers” to use a metaphor, at a high rate of speed and they didn’t slow down to allow us to tie the details back to rules.

It might help to describe the kind of test cases in question. It’s not as “simple” as user will do X and then system will respond Y. It’s a time-stamp based audit trail of data changes. Some date changes are allowed and some are not, some result in new records being created, and some do not. Some result in records being cancelled or deleted and some do not. We have several hundred different possibilities (test cases) all documented in detail and now we need to be able to distill that back up into business rules.

You have a project planning system? That must be nice. My mentee and I are the only ones on this business team with any experience with project management or Agile project methodology and we see this project quickly going off the rails, just based on our experience from other companies. Our BA lead and managers? No clue. Just feeling their way along.

I’ve always struggled with this kind of nonsense in my various jobs. And it never really seems to get better. I was talking to a mentor of mine (who is like 60 something, has a PHD, and loads of experience) and he told me that there is never an organization that does everything well, all the time. What ends up happening is that your current job has some task that it is very bad at, so you look for a company that does that task really well. And you’re like, “Oh, these guys know what they’re doing!” So then you join that organization and you realize that there was something they do really poorly, that your old organization did really well.

Very true, Chi. I guess what we should strive for is to find a company that’s messed up in the same way we are, or at least is messed up in a way that we can tolerate. I’m finding that I was more tolerant of such things when I was younger, but it also seems to have a high correlation with experience. Meaning that when I was new and didn’t know any better, I could easily do the work as instructed not knowing that I was doing it wrong or there was a better way. But now, with 30-years in a wide range of different companies under my belt, there’s not much that I’m naive about so I get frustrated much more quickly.

It also occurs to me that it would be fun (if not actually productive) to come up with some general business version of Joel Spolsky’s “Joel Test” for developers looking for jobs. I’m a bit too cynical now, though. It would end up being something like this:

  1. Do you use formal project management?
  2. Do you really, or do you just call it that because you just gave a developer or business analyst that title without any education or salary increase?
  3. How many “gate keepers” or “work preventers” are employed here?
  4. How high up are they in the corporate ladder?
  5. Do your employees laugh cynically as they proudly proclaim that “we don’t do documentation here!”

Etc.

I’d rather (I’m a PM) work for a company that has no formal project management than one that has a PMO that needs to change the process constantly and dramatically.

I’d rather work for one in a rut with processes that are well understood than one that grabs every single management fad of the moment.

I’d rather work for one that goes for incremental change and continuous improvement.

I’d rather work for one that invests in their tools and maintains them - rather than one that spends millions installing a new tool in a half assed fashion with unclear requirements, then saying “it doesn’t work” - and installing a new tool in a half assed fashion with unclear requirements.

I’d rather work for an organization that knows what documentation is appropriate - spending tons of time on documentation no one reads, or documentation whose sole purpose is to cover someone’s ass, is not useful. - A checklist for someone following a process is usually far more useful than pages of lengthy narrative.

My biggest soul suckers have been unethical behavior. A company that doesn’t bother to meet its regulatory requirements - which are actually, you know, important ones that protect the public safety. One that overlooks sexual harassment. One that doesn’t pay for its software. One that bills the client for work not done - they had good intentions of doing it - but you know, not the staff to do it, so they just didn’t bother (will anyone know that they contracted to back up their data and we haven’t done it for eighteen months - but they’ve been paying for it? Oh, by the way, its a law office :slight_smile: - we won’t have ANY issues if they find out. I left with “I really don’t want to give a deposition, I’ve done it before and they suck.”).

In my case, it’s the opposite. The older I get, the less I expect things to go smoothly.

What you said about “work preventers” struck home, though. OK, I know that so-and-so isn’t going to produce. That’s fine - don’t get in my way when I try to produce. Because I get irritated, and it is best not to irritate the cranky old programmer.

But stuff about project plans and deadlines and corporate mix-ups I can (mostly) laugh off. Because I recognize that it doesn’t really affect anything. The project planning system exists just to generate reports that say Shodan missed his deadline. And when someone important - team lead, my boss or his boss - asks me why, I can tell him “because I was working on defect XYZ so offshore can start testing again, and besides the deadline doesn’t mean anything because the feeding system isn’t ready”. And generally I can use the 80-20 rule - 80% of the work is gonna get done by 20% of the people. So I keep in direct communication with the 20% and prioritize so they get what they need.

But I have been doing this for thirty five years. And some MBA two years out of business school needs to learn that “do you want it Friday, or do you want it to work?” is a real question. And it doesn’t change anything because of a number on a report.

Overall, I like my job and my company. And I like being the grizzled veteran who knows how to make the magic box do tricks. Having something to complain about is part of the fun.

Regards,
Shodan

That’s that lack of initiative I mentioned upthread. It’s like those guys say “Welp… failed the test. Guess we’ll sit here until someone tells us what to do.” instead of seeing why it failed and how they can fix it.

The one that kills me is having project managers whose entire role is to manage the projects, but giving them no actual authority to get shit done. Ours are basically peers to the BAs who concentrate on the administration, while the BAs concentrate on being more of a subject matter expert and peer to the technical designer/architect types. But when push comes to shove, the project managers have to basically get some person with a fancy title to go to bat for them, instead of having any real authority to compel people to do what they need. Which in practice means that when things are easy, things are smooth, but when they get interesting, they automatically escalate, which to my mind, is a bad thing.