The Informatizer Plus – Issue 25

The Recession-proof Career

by Peg Bogema

For many, their understanding of the recession is a deeply personal view of the effect it had on one company—the one where they work(ed).

To illustrate the point, one company I know laid off every non-essential employee in the U.S., combined and consolidated roles so that everyone left was doing two peoples’ jobs (to make up for the lack of personnel) and instituted an across-the-board 5% pay cut. The company survived the recession and is doing fine now. But it was touch and go for a while and affected everyone in the company, some more harshly than others.

Certainly we talked with our friends and relatives about their jobs and shared stories like this one.

And, of course, the media provided insight into what was happening in many companies. But often the reporting was slanted in a specific way. For instance, there was a lot of coverage about the automotive industry here in southeast Michigan. But was it correct to generalize what was happening in that industry—assuming it was the same everywhere else? And there was even more coverage about the companies that went out of business, the people who lost their livelihoods, and so on. In the final analysis, newspapers and their brethren exist to sell ads, and the most sensational stories were promoted to page 1.

So what really happened to everyone else? And what are the lasting impacts?

If you are a salesperson, you get to go into numerous offices and dish with numerous people. Same for a consultant—like me. And here’s what I observed.

Hiring

Hiring was next to non-existent. The opposite was the rule of the day. Massive lay-offs. The target in any software or Web or embedded systems development group was the “non-essential” roles. So there was a blood-letting at the management echelons right down to the project manager. QA roles were eliminated. Technical writers were cut. Business Analysts were cut.

To compensate, all of these functions were piled on the remaining staff, that is, the software developers.

New Product Development

For most companies, new product development was scaled back or put on hold. Uncertainties in the marketplace made many companies nervous about spending money on new product development at all. I mean, seriously, if you made a new product, who would buy it? When sales plummeted, companies started hoarding their cash to ensure they could ride out the recession. Of course, when everyone is hoarding cash, the recession is prolonged because no one is buying. A bit of a chicken and egg situation.

Internal projects to automate and streamline business processes were likewise put on hold. No cash to fund them. Simple.

Temporary Employment

In cases where personnel were absolutely essential, temporary (contract) employment was the preferred mode. And that temporary employment was often price-constrained. The thinking was that with so many people looking for work that someone was bound to accept a low-dollar contract. Beats working at a cash register in a retail store for minimum wage, right?

Turning Point

I am sure that some economist can put his or her finger on the exact turning point when the recession ended. To me, it was so gradual that it was hard to find an exact moment when it got better.

At first, our clients started complaining about difficulties they were having finding qualified people. They brought us unusual—and often unrealistic—roles to fill (contract at first, and then direct-hire). Over time, the unrealistic expectations (like a tech lead who is also a project manager who is also a DBA for $80K) became more and more realistic—with wages moving upward, as well.

Then clients started to ramp up new product development.

And finally, clients have started to move on business process improvement projects.

We find ourselves in a highly competitive hiring and contracting market. This is made more complicated by the fact that numerous technical personnel moved out of Michigan to find employment during the darkest hours of the recession. Also, many people are hanging onto their current employment, on the bird in the hand worth two in the bush principle. Those who are willing to leave their current employment will do so only for direct-hire opportunities.

Take Aways

For technical personnel, there is one key take away: be as multi-faceted as possible. The person who can fill multiple roles is extremely valuable during a recession because he or she can do the work of several people. A project manager who is only a project manager is more likely to be affected by a lay-off than a project manager who can cover some other role. Along the same multi-faceted lines, the developer with strong customer-facing skills is more valuable than a head-down developer. Whether the developer works with external or internal customers, he or she can handle business analysis or customer support—once again reducing the likelihood of being laid off.

A second take away for technical personnel is this: do not let your technical skills stagnate. Some companies will keep a developer on staff to support legacy applications because no one else wants to do it. A tool like FoxPro, which has passed its end of life date, isn’t something people are clamoring to use. During normal, healthy times, a company will pay someone to maintain the legacy applications with no questions asked. But when layoffs are a necessity, that same developer is the first to be let go, the assumption being that some other developer will be able to spin up on the tool and make minor support type changes. We have observed this with a handful of candidates; their outdated skills make them very difficult to place. This can be mitigated by pursuing formal training or certification or diversifying with other non-technical skills.

For companies, there are several take aways that stand out. One is to invest in cross-training technical personnel so it is less painful to maintain a development activity during financial stress. It’s one thing to have fewer people. It’s quite another to have zero experience with a vital competency. Zero QA? Zero project management? Zero business analysis? Ouch.

Another take away is to take the initiative on training legacy developers in new technologies. The legacy developers have substantial domain knowledge, making them valuable members of the team. Rather than spelling their doom by keeping them sequestered in legacy coding, train them on new technologies or skills.

And as the hiring and contracting heats up in the waning days of a recession, understand how to attract good candidates. In some cases, it is as simple as offering the best compensation. This can often be as little as a few thousand dollars annually. In other cases, a more nuanced understanding is required. Identifying the key skills that are needed will open the door to many more candidates applying for roles. Out of those candidates, there will be at least one who is abundantly trainable in those areas that may be required but which are relatively easy to learn.

Peg Bogema is Stout’s Vice President of Operations. With Stout since 1997, her duties include the supervision of development projects and personnel, recruiting and accounts.

What’s New in Project Management

by Matt Wickey

I recently attended a conference on agile software development. It was a well-attended event with interesting breakout sessions and renowned keynote speakers. There were talks on radical management techniques, post-agile software delivery methodologies and related experiences “from the trenches.” All of this was interesting but one of the most interesting tidbits I picked up there was that PMI now offers an agile project management certification.

What is PMI you ask? It is the Project Management Institute—the organization that provides the primary professional certification for project managers. This certification, called the Project Management Professional (or PMP) is the acknowledged gold standard for professional project managers in a number of fields.

To be fair, PMP certification is not required to be a successful project manager. And the PMP certification process is not as rigorous as for other professional certifications like that of a CPA. But it does convey an understanding of a body of knowledge that represents the current state of the art in project management. In fact, the knowledge required to pass the PMP exam is called the Project Management Body of Knowledge or PMBOK.

The history of PMP certification is that it was meant to promote the application and standardization of project management techniques across the industries where this type of management is beneficial. Software development is one of these industries—but so is building construction. One unintended consequence of this standardization is that, for years, software projects were executed a lot like building projects where the required steps are performed in a well-defined, sequential order. This is the old waterfall model we all know and love.

It’s not that the waterfall model is bad per se. It still does perform very well in the construction industry where project steps are well defined and the sequential order is necessary. However, the experience with waterfall projects in the software world is quite spotty and is highlighted with projects that run long, bust budgets and under deliver functionality. Let me be clear, there is nothing in the PMI certification regimen that dictates the waterfall methodology must be employed. But, for whatever reason, the image of PMP project managers leading waterfall software projects is engrained in the minds of many in the software community.

On the other hand, agile software development methods are seen as the antithesis of waterfall and, in turn, to the PMP. It pays to remember that agile techniques were developed by software developers for software developers. They are rooted in the belief that if managers (especially project managers) get out of the way and let software teams do their best work, then software will be created more quickly, it will be of higher quality and it will be more in line with the desires of the users. More generally, agile software methods (Scrum for example) codify the belief that project managers do more harm than good. In fact, Scrum projects are designed to work without project managers. There is the role of a Scrum Master. But, as someone who has performed both roles, I can tell you they aren’t the same thing.

So, all this history takes me back to when I first found out the PMI is now offering a PMI Agile Certified Practitioner (PMI-ACP) SM certification. I see this as something akin to dogs announcing that they want to be more cat-like. I can tell you for sure there are many agile software developers who have no interest in certifications or project managers at all. So how is it that PMI can figure that offering an agile certification will fit its mission? Aren’t they polar opposites?

This offering by PMI is a combination of two themes, one purely pragmatic and one that is in keeping with their mission.

From the pragmatic standpoint, even PMI admits that the majority of software development organizations today are, to some extent, agile. In fact, the advent of these methods is recognition that software projects and building projects are not the same. And, since software is one of the core industries served by PMI, there is no way the organization could ignore the agile revolution and remain current. In other words, PMI is offering an agile certification because they have to. Without it, they would become irrelevant in the eyes of the software community as a whole.

As for the mission, remember the PMBOK that represents the Project Management Body of Knowledge? When studying this, it is explicitly stated that this body of knowledge is not static. And no one version of this book will represent all there is to know about project management forever. Project management is a dynamic field where new techniques evolve and the body of knowledge must evolve as well so that it always represents the state of the art. As such, PMI is adding an agile offering because it is part of their core mission to do so. To continue to deliver value to their constituents, they cannot ignore a movement as significant as agile.

For me, the interesting question is where will PMI go from here? Will these agile methods migrate from a secondary certification to part of the PMBOK as a whole? Could the PMBOK make these changes and still adequately represent cross-industry project management? Or are agile methods so distinctly software-based that they must diverge and form a new “software only” PMBOK? What we’re watching is the evolution of project management before our very eyes. I, for one, am interested to see where this will all lead.

Matt Wickey is an IT professional and project manager with over 20 years’ experience. Matt holds Bachelors and Masters Degrees in Computer Science. He is also a PMI certified project manager.