So How Did You Become a Project Manager?

I’d really like people to answer this one for me….so please get ready with your comments. It’s a much more recognized field now than it was 20 years ago so you now actually see people getting degrees in project management and planning a career in it. But that definitely wasn’t the case 20+ years ago – at least not for me. What’s your story? I’d like to hear it and everyone else probably would as well. Tell us. Here’s mine.

How Brad Egeland Came to Be a Project Manager

Ok, this is not going to be an adventure story – that’s for sure. Some of you may already have heard some or all of this before because I think I’ve already included some info about this hidden in a past article somewhere. But, for the new readers or the ones who just can’t get enough of this info (yeah, right?)…here goes…

My father came straight out of college and started the IT department in the 1950’s for a large Midwestern grocery store chain based in my home town. I told him growing up that I was not going to have anything to do with computers. I even continued that stance as I started working for him after I turned 16 as a computer operator running card decks through card readers and loading large backup tapes on tape drives (and lots of mischievous things late at night in the warehouse involving the golf carts that the security guys would use to go from station to station….ah…good times!).

In fact, I was going to be a pharmacist (why?). I even started out in pharmacy my first year in college. Nothing against pharmacists…my brother is a pharmacist…but that just wasn’t for me. I moved over to the business/MIS track and took one – count ‘em – ONE programming class…COBOL. That landed me my first job right out of college in the mid-80’s as a COBOL mainframe programmer and guess what, I was doing something with computers. My dad was right…again. Oh well.

Application Developer

I quickly became a system lead on a large government contract – the organization I worked for primarily bid on and won large education-related government contracts. We’re talking in the $100-200M range lasting 3-5 years. So there was a lot of opportunity for responsibility fast…and a lot of opportunity to play significant proposal roles in winning new contracts…which led to opportunities for new roles on the new contracts.

First Manager

I also should mention that I had a great friend and manager at the time – he’s now a CTO in Minnesota, but he was a great career mentor to me back then and could see I wasn’t the type who would be happy coding 8-10 hours a day forever. He helped me shift gears, move into proposal roles and then into roles on new contracts that placed me in line with program and project management responsibilities. My first move from development was to a configuration manager role on a new contract our company had stolen from the incumbent.

From there I moved into multiple project administration roles (managing program budgets, change orders, configuration/change management, and financial forecasting) on contracts before accepting a key contract position as a Deputy Project Manager on a 5 year education contract. This was my first true ‘management’ role with actual hiring/firing/etc. responsibilities over resources – and also made me the youngest true manager in the history of the company at that time. That’s changed since then as they’ve grown and the need for actual managers has grown as well.

The Big Jump

Since moving into the role of Deputy Project Manager in the early 90’s I’ve had various PM and PMO roles and responsibilities – my last 18 years have all been filled with project management and PMO leadership roles. The organizations have changed, the industries have changed, the types of customers I’ve served have definitely changed, but the principles that guide me in my PM work have remained the same – those characteristics of a project manager are applicable to whatever customer, industry or company you’re working with. Methodologies, templates and processes get tweaked, but the fundamentals are usually about the same….organization, timely reactions, ownership, honesty, stubbornness, willingness to lead, etc. Those things remain the same – and continue to drive me down the right path to this day.

Well, that’s my story…were it not for an ill-conceived route through college starting with chemistry classes and ending with system design classes and a good mentoring manager as my first supervisor, I may not be here, but I’m glad I am.

Tell us your story…

Dashboard Data for Government IT Projects

Since we’ve done a decent amount of discussion here on project status, project budgets, on schedule, behind schedule, and project dashboards in general, it was refreshing to read the federal government’s CIO, Vivek Kundra’s idea of making IT project data available for everyone to view. And he wants it completely unfiltered. He’s correct in stating that data gets too much massaging…that happens too much in the private sector – imagine how much it can happen in the public sector.

The following info comes from J. Nicholas Hoover’s article for InformationWeek and I find it a breath of fresh air for those of us who have been managing projects a long time and priding ourselves in presenting meaningful, realistic data even when it hurts. And I have worked a great deal in the public sector on large government projects – much bad news can get hidden if you choose to go that route. It’s nice to see them wanting to take the high road with the tax payers’ dollars.

Federal CIO Wants Unfiltered Data on IT Projects

Federal CIO Vivek Kundra is looking to improve the data that’s available on the effectiveness of government IT projects by tapping directly into systems that collect data on those projects.

Speaking during a town hall yesterday at the Open Government and Innovations Conference, Kundra said there are “too many people in between” the government’s recently launched IT Dashboard and the original sources of data made available there. The IT Dashboard is a Web site that discloses information about government IT projects, including whether those projects are on schedule and on budget. “Data gets massaged too many times,” Kundra said.

As part of the IT Dashboard, projects that are significantly over budget or behind schedule get highlighted in red in charts that show agency IT spending. Kundra acknowledged concerns among government IT professionals and CIOs that employees would be scrutinized and their job effectiveness judged on whether projects were in the red.

“It’s okay if a project is behind schedule as long as we understand what’s causing the delay,” he said. “Just because something’s red is not cause for panic.”

Kundra acknowledged that the IT Dashboard doesn’t do enough to recognize the successful outcomes of IT projects and said his office is working add that capability to the IT Dashboard. The challenge is to insure that performance and expenditure data are integrated in the process, he added.

Kundra said his office is looking at a number of federal regulations and policies, including the federal policy on cookies and the Paperwork Reduction Act, to assess whether they continue to make sense in today’s technology environment.

His team is also looking at FedBizOpps, the government site that lists procurement opportunities for private industry, to see if technology like RSS feeds can be added to make it more usable.

Balancing Critical Project Success Factors – Engaging Conflicts Directly

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” This is the fifth installment in a six-part series entitled Balancing Critical Project Success Factors. In case you’ve missed the first four, here’s what we’ve covered so far:

• Introduction
• Selling Good Ideas
• Building a Common Vision
• Generating a Commitment to Ideas

In this fifth segment we cover engaging conflicts directly and resolving them efficiently and effectively.

Engage Conflicts Directly and Resolve Conflicts Efficiently and Effectively

Once project plans are underway, change happens. Requirements shift, the client does not meet its obligations in the project plan, and budgets can be reduced. Changes within the IT group can also occur. Tasks may exceed initial estimates. Key programmers leave to join other firms. Differences in opinion among IT professionals about the best approach can erupt into conflicts that push projects off track.

When this happens, IT professionals must assertively engage key stakeholders (e.g., users, user management, IT management) in problem solving about the trade-offs that must be made in quality, time, cost, and perhaps even customer service agreements. Assertiveness is critical because users (and admittedly IT management on occasion) would prefer to avoid making necessary but difficult decisions about trade-offs between quality, time, and cost. Interestingly, resolving such conflicts may be best viewed as a typical and not unusual part of what IT project managers do. In survey research of professional project managers, it was discovered that they report spending an average of 12 hours per week resolving conflicts.

When engaged in problem solving about trade-offs, stakeholders sometimes become frustrated and retaliate by challenging the competence or creativity of the IT project manager. IT professionals sometimes respond to such challenges by retreating from their legitimate interests. In a misguided effort to please, some over-commit to all three factors although significant changes in the project environment necessitate adjustments. The result is priority overload, stressed-out IT personnel, a loss of credibility and influence, suboptimal IT work products, or missed timelines.

Assertively championing one’s basic interests, exploring alternatives with affected parties even when they are not enthusiastic to do so, and collaborating to construct win-win agreements is the better response. Unfortunately, many people drawn to information technology (like many drawn to other technical disciplines) have a personal aversion to conflict. Consequently, for some IT professionals, enhanced negotiation skills is necessary.

Faithfully applying project management disciplines can limit the amount and scope of project conflicts that IT professionals have to manage. Conducting risk assessments early in the project life cycle to identify factors that might threaten project deliverables is one such discipline. If a risk is detected early (e.g., weak user management consensus on requirements) and focused problem solving occurs about what contingencies are necessary to address it (e.g., identifying a resource that can be used to do team conflict resolution with user managers), project disruptions caused by the risk can be effectively contained.

Providing regular user management updates is a second project management discipline. When updates work most effectively, not only is progress reported, but threats to project deliverables are reviewed and user management support of efforts to limit or resolve those threats is secured.

For some complex projects, more substantial organizational conflict management mechanisms are required. On large IT initiatives, the relative priority of the needs of different user groups can change over time. Because IT resources are often relatively fixed, reallocating resources to respond to a increased urgency for one user often means reneging on commitments made to other users. To address shifting priorities between users, some IT groups convene regular, periodic meetings of steering committees or users councils. When such mechanisms work well, users collectively learn about urgent priority changes, explore alternative responses to these situations, and finally make mutual decisions about priority changes and IT resource reallocation. In these settings, IT professionals facilitate the preparation of information that enables these groups to make sound decisions. By promoting quality dialogue between users, IT professionals enhance organizational problem solving.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Balancing Critical Project Success Factors – Selling Good Ideas

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” In the Introduction article we outlined the five prescriptions for preserving the balance between project success factors. In this article, we look at the first prescription – sell good ideas by emphasizing benefits that the user perceives as valuable.

Selling Good Ideas

The starting point for an IT project is selling senior management within the user group and within the IT function on the idea. Consequently, the efficiency with which ideas are sold is one important means of managing priority pressure. The power of persuasion depends largely on whether the rationale used to support an idea resonates with the decision-maker’s interests. To sell ideas more efficiently, the rationale for an idea must reflect the user’s priorities. In short, reasoning should always outline “what is in it for them.”

When selling ideas, IT professionals sometimes get stuck on technical issues, specifications, and justifications. Although technical details are critical, as facts, they have limited power to influence users and senior IT management. As a result, one of the main priority management prescriptions is that IT professionals need to develop sufficient business expertise to engage users in terms that they will find compelling. IT professionals who add this expertise to their technical competence have the greatest organizational impact. Many IT organizations are experimenting with the role of user or client relationship manager to help establish client sensitivity within IT organization.

Selling ideas effectively also means having good ideas. Good ideas are designed with knowledge of the practical time and resource constraints within which they will be implemented. Not all business problems require state-of-the-art solutions.  Sometimes, small is beautiful. Making incremental enhancements over time can moderate the negative influence of organizational politics, limit risk, and create success experiences. A track record of successful enhancements can build momentum for bigger, more ambitious projects.

Having a good idea is not sufficient, however. Good ideas are often not met with enthusiasm. How the IT professional responds to the objections raised by others as the idea is being sold affects one’s eventual success. Arthur Schopenhauer, the nineteenth-century philosopher said that ideas go “through three distinct phases: ridicule, opposition, and finally enthusiastic acceptance.” Advancing ideas through these phases means (1) increasing perceived need for the idea, (2) modifying the idea itself to increase personal and organizational benefits to key stakeholders, (3) reducing costs, both personal and organizational, and (4) decreasing perceived risks. By adjusting good ideas iteratively based on feedback from stakeholders, IT professionals can efficiently win a critical mass of support for IT projects from key stakeholders.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Balancing Critical Project Success Factors – Introduction

I found this excerpt to be applicable to what I’ve been writing about customer satisfaction lately from a project management perspective as well as a worthwhile read overall. This comes from Paul Tinnirello’s book entitled “New Directions in Project Management”.

In this section, Mr. Tinnirello introduces 5 prescriptions for preserving the balance between project success factors. Over the next few days we’ll look at each 5 of those prescriptions in greater detail. Read on….

A Question of Balance

As IT budgets have soared and user demands for optimal ROI have increased, managing quality, time, and cost must be accomplished with recognition of a fourth critical project factor — customer satisfaction. User complaints about a lack of responsiveness, the inability of IT professionals to engage users about their IT needs in “user-friendly” terms, a lack of reliability about time lines along with related service sins have all produced a heightened awareness of customer satisfaction and the means used to secure it in many IT organizations.

To address the greater importance of customer satisfaction, the quality, time, and cost framework introduced earlier has been expanded. Exhibit 1 displays this expanded view of IT project management.

The implication of the quality, time, and cost framework is that IT professionals must balance alignment among the task factors (i.e., quality, time, and cost) with the press of the relationship factors (i.e., customer service and customer satisfaction). If IT professionals allow the balance to tip too much in the favor of task factors, too little emphasis is given to the relationship factors. Project managers may successfully complete the tasks on their project plans but create off-target work products and frustrated customers.

On the other hand, if the balance is allowed to tip too much in favor of the relationship factor, the opportunity to deliver timely and cost effective work products is lost. Creating a service balance is the second major theme underlying changes in the IT field. When the balance is achieved and maintained, IT professionals come to be respected as business partners by users because they build useful work products for satisfied customers.

Viewing IT work through the lens of this project management framework emphasizes the importance of balancing four critical project factors: quality, time, cost, and customer satisfaction during project planning and later in the project life cycle. To achieve and maintain this balance, IT professionals must directly engage in the power and influence dynamics of implementing organizational innovation.

Productively managing these dynamics helps preserve the balance between the project factors and enhances the IT professional’s ability to manage priority pressure.

Five prescriptions for achieving this are as follows:

• Sell good ideas by emphasizing benefits that the user or customer perceives as valuable.

• Build a common vision of project outcomes and how people will work together to achieve them.

• Generate commitment to ideas or implementation plans by getting users to modify them in the direction of personal and business interests.

• Engage conflicts directly and resolve them efficiently and effectively.

• Assertively enforce standards of IT excellence.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.