Getting Started

By Cinda Voegtli

This column is about "getting started": the start of projects and the start of new jobs or roles. I'll give an overview of the two issues in this column, then follow up in future columns with detailed discussions of the roles of different project team members in these "start" situations.

Earlier this year I attended a project management conference, and participated in a roundtable discussion over lunch about managing technical projects and teams. This roundtable was very informal - eight people who wanted to talk about their current project issues and pick the brains of their colleagues for an hour while we ate. Our table included software consultants; software and IT project managers; a computer company project manager; a banking services project manager; and software engineers who had just been given new assignments as project managers. The main issues at the table revolved around the two kinds of starts - new projects and new roles. I'll talk about two of the issues they raised, to highlight situations that affect us as engineering professionals.

The banking project manager's biggest challenge was getting the business people and the technical people to talk to each other thoroughly at the beginning of the project, so that they'd have a chance of delivering the right product to their internal customers. The business people and the technical people didn't really understand what they had to talk about early on! The business folks wrote down a few requirements and threw it at the engineers. Those developers thought they were supposed to just implement the requirements even if they didn't fully make sense, even if they couldn't be implemented in the required timeframe, even if they involved huge technical risks. Lots of good information was being lost early on, and her company's projects often seemed chaotic and off-target, with tense relations between the two groups.

The software-engineers-turned-project-managers had a different "start" issue: how to handle their new role as project managers. The immediate good news is that they were already taking a first great step by attending this project management conference. I personally didn't get any formal project management education until several years into my new role; and I didn't even know enough back then to go seek it out! I wish someone had told me back then that I needed to do what these two new managers were doing-- take the initiative to get education and assistance for a new role. But they weren't sure what else to do to get prepared.

By the end of lunch the group had fragmented into two conversations. The banking project manager was talking intensely to the two software consultants, because they had evidently dealt extensively with the business vs. technical culture she had and the "start" problem around early requirements definition. They had some very concrete techniques for her to use for effective project kickoffs, to show the engineers how to contribute to the business discussions, and show the business people what kinds of contributions the technical group could make to the requirements definition and tradeoffs. (We'll cover this subject in detail in the next column.)

My side of the table was busy giving the two new project managers every shred of advice we could come up with from our hard-won experience for the first problem they were facing. Their project had its own "start" problem - the corporate communications group was refusing to be involved early on in the team's web development project. According to one project manager, this group's input was critical during the early design work, to make sure that the development group was getting the website look and feel right to match the corporate image. (If they didn't get the first round of development right, they'd have to spend another $20,000 to redo it.) We admonished him to not just do without their input, use the financials to highlight the importance of their input, and a few other tactics for getting their involvement. As he left the table, one of the new young PMs said "you guys just saved me two weeks of agony!" and "this was a great way to get my education for this job jump-started!"

When all these project managers left, they had new help for all their "start" efforts. All because they took the initiative to look for new inputs, new answers, new ways to perform their own roles to help make sure their technical projects would be successful.

As a technical professional, a project manager, a business leader, or a project executive, what new projects or new roles are you starting? Are you prepared? Do you know your responsibilities and how you fit with the overall effort? Do you know how to further your own education and capabilities to make these efforts great? These engineering colleagues left with ideas about how their other technical team members could make critical contributions to their projects and how to prepare themselves further for their new management roles. We'll talk more about how to do the same for ourselves in our next "All Together Now" column.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy