It was a great company to work for. The folks were all so nice, the training program was robust, and the work was interesting. It was a family-run business that really felt like family. After a rough 5 years with a big consultancy, it felt like a safe place to land. It was the kind of company that held its own annual chili cook-off, gave every employee a gym membership, where the CEO regularly invited programmers and testers and admins and agents to lunch and listened to them, and you actually looked forward to the monthly all-hands meeting.
The project management team was a
good team with a decent manager. We liked each other, helped each other out, and
had lots of conversations about doing things better. We were earnest and eager young
professionals, most of us holding the title “project manager” for the first
time.
We decided that we needed to
develop some standard processes and all use the same project management tools
to make it easier to track the status of all our work across the different
software products we produced and supported. We were in the mode of doing small
waterfall/iterative projects, each of us often managing several projects at one
time. We settled on Microsoft Project and then turned to standardizing our PM
processes and plans.
The only problem was that I quickly became the contrarian. I didn’t set out to be, but you know how it goes. I was working with the web team almost exclusively. I started out with a small site design for a subsidiary company. The creative component of web design appealed to me. I liked the team I was working with. My product manager was the wife of an astronaut and given to wildly personal confidences over the salads at lunch. The business analyst was a working musician with a voice like an angel. The webmaster was a fidgety and flirtatious drummer who was a bit of a genius at graphic design. The dev manager was a bass player known for always ordering the largest and most expensive item on the menu whenever we had a team lunch. The QA manager was a handsome Italian-American-Mormon with some weird hang-ups. Over the course of multiple projects, we evolved into a tightly knit, scrappy little family.
For a big internet project like
redesigning a site or adding major functionality, the established project processes
worked just fine. We had natural and distinct design/code/test/launch cycles of
the work. Breaking a big project into multiple releases still worked within the
methodology. But our leadership decided that every website task we did had to
fall within a project and be managed as such. Adding a link, refreshing some content,
building one or two new pages, or other small site-maintenance tasks just
didn’t fit into that framework. At that time, self-publishing tools such as
marketing teams use everywhere now just didn’t exist, so all website changes went through IT. I found myself wedged
into a corner called “do what you’re told and make everyone miserable or do it
the right way and get yer ass fired.” Not a fun place to be.
“I need an alternative to our PM process
for this type of work,” I told my manager. “My stakeholders are frustrated
because things take too long.”
“You’ll just have to bundle all of their
requests into a project,” she told me.
“But that will delay our response
for possibly weeks,” I retorted. “And there’s no value in grouping tasks
together into projects if they really aren’t a project. There’s no relationship
between them, so there’s no synergy in projectizing them.” (Consultant-speak
oozing out of every pore. I don’t deny it.)
“That’s the way we do things,” she
said. “They’re going to have to get used to it.”
Dear reader, they didn’t get used
to it. The marketing department loved our work but they hated our processes so
much they hired their own webmaster and cut us out of the loop completely.
Turns out, about the time I was fighting this battle, something called Agile
was crawling out of the swamp. Maybe it would have saved me. Maybe not. More on
that later.
