Talk about luck. I’ve been fortunate (?) enough to have managed or assisted with the installation of products from both titans of the Enterprise Resource Planning world: Oracle and SAP (three if you count Peoplesoft, which Oracle swallowed in 2004). As I’ve come to understand at the cellular level that these types of projects are in a class by themselves, I’ve also discovered what I consider to be the most important success factors for project managers involved in ERP projects.
Type “ERP implementation nightmares” into Google and you’ll receive over 6000 results. CIO.Com recently listed several botched Oracle and SAP rollouts in their “25 Terrifying Information Technology Horror Stories” article, for example, not even including the cancelled 2007 Philadelphia water billing system project which ranks among the biggest Oracle catastrophes ever. The roll call of blown budgets and endless delays underscores the multifarious nature of ERP projects. These implementations can be among the most complex and challenging that an IT project manager will ever face.
This is hardly fresh news, but I want to provide my own take on some of the biggest ERP headaches and on the solutions that I actually helped implement. These lists are far from all-inclusive, but I hope they give potential PM’s some idea what they might be in for when they sign up for an Oracle or SAP installation.
The “Big Three” Issues
• Integration and Interface Development: How well does the new package link up to existing upstream and downstream systems (such as legacy data, data warehouses, external partner systems or reporting tools?) I’ve seen programmers tear their hair out trying to get data to transmit correctly using EDI, and struggle endlessly to chase down why information doesn’t display properly in reports.
• Customization: No off the shelf product is truly plug and play. ERP projects usually involve massive amounts of work to accommodate the system to each organization’s homegrown terminology, processes, workflows, and standards. Sometimes this feels like pounding a round peg into a square hole.
• Impact to Business Processes: An Oracle or SAP installation will usually force organizations to alter procedures and workflows, sometimes drastically, to accommodate the design of the package. This widens the net of stakeholders and boosts up the project risk level considerably. Yet some executives cling to the delusion that ERP products can simply be plugged in to host and enhance their current processes.
Success Factors
• Before even starting: The business needs to crunch the numbers and truly quantify the business benefits that ERP should bring. (You would think that this would be a no-brainer for a multi-million dollar investment, but I know of one organization that simply assumed that the benefits were “self-evident given the state of the current system.”) They should invest more time than ever defining requirements, success criteria, even entry-exit criteria by phase. Part of this will be choosing which elements of the vendor package are required to meet these requirements (SAP and Oracle have Financial, HR, CRM, and more components) and where gaps may remain. The business also needs to decide which parts of the company that the new system will be rolled out to, and negotiate strong terms and conditions in the contract for the system’s performance so the vendor can’t leave them in the lurch. All sound too basic? You’d be surprised how often enterprises skim over them in the name of expediency (and later pay the price.)
• Let the end users participate in the design process. This should be mandatory. After our Peoplesoft Global Financial implementation, for example, the accounting clerks pointed out that a journal voucher now took twice as long to enter is it did using the old system, thanks to a screen progression that we could have easily customized to flow better. (On the other hand, giving users too much control can have even worse results, as the PMs for the Philadelphia Oracle installation discovered.)
• Most important of all - find the right project manager. It’s not enough that the PM has sufficient ERP implementation experience for technical credibility. These projects also require much stronger business savvy then the manager of a smaller scope would ever need. The ERP PM will be a mini-executive negotiating with executive stakeholders and championing an effort that impacts the length and breadth of their organization. The Senior PM who ran our SAP CRM 3.1 install, for example, was interacting daily with Senior VPs and making decisions that profoundly impacted the operations of the company. A mere technician would have been in way over their head.
Thursday, January 22, 2009
Friday, January 16, 2009
Beware the Robotic Horse
I once had a coffee table book covering the early years of the auto industry. It was full of pictures and diagrams of the first crude proto-cars, some featuring these hilarious oversized boilers and even cowcatchers. But the one illustration that stuck in my mind was that of a fully mechanical horse. Some 1890s engineer had actually created a blueprint of a steam-driven robotic replica of a horse, big enough for someone to mount and ride, as if people could not conceptualize a mode of transportation that didn’t look like Mr. Ed. If it moved people, in this guy’s eyes, it clearly had to have four legs and a long face.
IT projects can easily fall into a similar trap. When we redesign a workflow or process, breaking free from the mental model imposed by the current system can be a tough go. Too often we build a solution that (consciously or unconsciously) replicates the existing environment, whether or not it makes sense to repeat all the same steps to generate results. Once you hear the famed expression “but we’ve always done it this way” you’ll know what I’m talking about.
For example, years ago at my last organization I managed a project to automate the generation of standard project contracts. The existing workflow was manual, paper intensive, repetitive, slow, and cumbersome. The vendor’s software package boasted features such as secure online approvals at each level and customized clauses. But the project ended up being canceled before it even hit the development phase. Why? Certain constituencies insisted on being able to print out a contract midway though the workflow, mark it up manually with their red pencils, then somehow have their markups recaptured by the system. They simply couldn’t conceive that editing on a screen was as meaningful as editing on a piece of paper, since that was they way that had always done it.
These customers refused to budge, and the coders soon threw their hands up in exasperation trying to design a technical workaround. It was an impasse that not even the executive sponsors could negotiate through, so we pulled the plug on the project. (And to this very day, years later, the organization in question still devotes way too much time to manually passing around draft contracts.) The famous mechanical horse had struck again.
Designing a “clean slate” solution is easier said than done. Good project managers can prepare for resistance to change by working up front with customers during the requirements definition phase to identify any must-haves that are part of the current process. Great project managers, on the other hand, also have the ability to truly persuade even diehard partisans of the old process that Change Is Good. They can demonstrate clearly that these customers will lose nothing and gain much by trading up to a better technical solution. Such as one with wheels instead of piston-driven legs.
Using basic negotiation techniques can help. Uncovering the "what they want" behind the "what they are saying" is a good start. Customers may tell you that they can't edit a contract without holding a paper copy, for example, but what are their true concerns? Security issues? Being able to convey certain nuances? Discomfort with the user interface? Part of the PM's role is to dig down to this level. Otherwise, the mechanical horse might be rearing up in your future.
IT projects can easily fall into a similar trap. When we redesign a workflow or process, breaking free from the mental model imposed by the current system can be a tough go. Too often we build a solution that (consciously or unconsciously) replicates the existing environment, whether or not it makes sense to repeat all the same steps to generate results. Once you hear the famed expression “but we’ve always done it this way” you’ll know what I’m talking about.
For example, years ago at my last organization I managed a project to automate the generation of standard project contracts. The existing workflow was manual, paper intensive, repetitive, slow, and cumbersome. The vendor’s software package boasted features such as secure online approvals at each level and customized clauses. But the project ended up being canceled before it even hit the development phase. Why? Certain constituencies insisted on being able to print out a contract midway though the workflow, mark it up manually with their red pencils, then somehow have their markups recaptured by the system. They simply couldn’t conceive that editing on a screen was as meaningful as editing on a piece of paper, since that was they way that had always done it.
These customers refused to budge, and the coders soon threw their hands up in exasperation trying to design a technical workaround. It was an impasse that not even the executive sponsors could negotiate through, so we pulled the plug on the project. (And to this very day, years later, the organization in question still devotes way too much time to manually passing around draft contracts.) The famous mechanical horse had struck again.
Designing a “clean slate” solution is easier said than done. Good project managers can prepare for resistance to change by working up front with customers during the requirements definition phase to identify any must-haves that are part of the current process. Great project managers, on the other hand, also have the ability to truly persuade even diehard partisans of the old process that Change Is Good. They can demonstrate clearly that these customers will lose nothing and gain much by trading up to a better technical solution. Such as one with wheels instead of piston-driven legs.
Using basic negotiation techniques can help. Uncovering the "what they want" behind the "what they are saying" is a good start. Customers may tell you that they can't edit a contract without holding a paper copy, for example, but what are their true concerns? Security issues? Being able to convey certain nuances? Discomfort with the user interface? Part of the PM's role is to dig down to this level. Otherwise, the mechanical horse might be rearing up in your future.
Thursday, January 15, 2009
Agile Methodology Is Making “Scope Creep” Obsolete
Project managers often list scope creep as one of their biggest headaches. But is documenting all the requirements of a solution before work ever commences truly reasonable? Perhaps what we refer to as scope creep is merely scope refining or scope development, and real issue lies with our own project management methods.
Let’s say that you need to replace your car’s starter motor. After hours of digging into the engine block to remove other components and just access this piece, the mechanic tells you that you also need a new solenoid. Declining to replace the solenoid would be foolish. It would mean another breakdown in the near future and a repeat all of the preliminary labor. So you add the new solenoid to the scope. In a project sense this represents scope creep (plus you will finish over your original budget and with a delayed schedule.) But was it the wise choice? Undeniably.
Traditional project management has long been rooted in “waterfall” development methodogy, a linear, structured approach. This method assumes that almost all requirements are locked down before a line of code is written. Progress is marked more by documents and artifacts such as a DDD (Detailed Design Document) than working code. But this approach can be inflexible and unrealistic when it comes to the demands of 21st century software development projects.
The answer in recent years has been Agile development methods such as Scrum and Extreme Programming. These methods aim at handing over the highest valued functional code elements as soon as possible, and continually improving these elements with each new iterative cycle (AKA “timebox” or “sprint”.) The iterations, which may be only a couple of weeks long, can encapsulate all of the steps of a regular development lifecycle (planning, analysis, design, coding, testing.) In an Agile world the highest development risks are frontloaded, and priorities are reassessed after each turnover.
Agile methods are naturally less bureaucratic, embedding only the minimum processes and controls necessary to manage the effort. Visa visionary Dee Hock once noted that “simple, clear purpose and principles give rise to complex, intelligent behavior…. complex rules and regulations give rise to simple, stupid behavior;” an Agile culture exemplifies this spirit. In this new world, the bywords are collaboration and rapid adaptability. Customer-developer interaction (a big taboo in the tightly controlled waterfall world) is encouraged, delivery of working code is emphasized over technical documents, and even 11th hour changes to requirements are par for the course.
Unsurprisingly, not all organizations have welcomed Agile methods with open arms. Some have characterized it as “cowboy coding” and are reluctant to deviate from their own highly codified and disciplined methodologies. But the stereotype that Agile equates to a lack of discipline or planning are beginning to fade. As current economic circumstances force companies to reassess the business value of complex and burdensome project management methods, more organizations are turning to Scrum, XP or Agile UP. A track record of success stretching back over a decade helps to convince the doubters.
IT projects that have fully fleshed out requirements up front are a rare exception, but too many organizations still run projects based on this premise. Agile methods simply recognize the reality that customers can change their minds. Concepts such as “scope creep” or “requirements churn,” the bane of the waterfall world, no longer have any meaning in this new context. And when working software is the primary measure of progress, what’s not to like?
Let’s say that you need to replace your car’s starter motor. After hours of digging into the engine block to remove other components and just access this piece, the mechanic tells you that you also need a new solenoid. Declining to replace the solenoid would be foolish. It would mean another breakdown in the near future and a repeat all of the preliminary labor. So you add the new solenoid to the scope. In a project sense this represents scope creep (plus you will finish over your original budget and with a delayed schedule.) But was it the wise choice? Undeniably.
Traditional project management has long been rooted in “waterfall” development methodogy, a linear, structured approach. This method assumes that almost all requirements are locked down before a line of code is written. Progress is marked more by documents and artifacts such as a DDD (Detailed Design Document) than working code. But this approach can be inflexible and unrealistic when it comes to the demands of 21st century software development projects.
The answer in recent years has been Agile development methods such as Scrum and Extreme Programming. These methods aim at handing over the highest valued functional code elements as soon as possible, and continually improving these elements with each new iterative cycle (AKA “timebox” or “sprint”.) The iterations, which may be only a couple of weeks long, can encapsulate all of the steps of a regular development lifecycle (planning, analysis, design, coding, testing.) In an Agile world the highest development risks are frontloaded, and priorities are reassessed after each turnover.
Agile methods are naturally less bureaucratic, embedding only the minimum processes and controls necessary to manage the effort. Visa visionary Dee Hock once noted that “simple, clear purpose and principles give rise to complex, intelligent behavior…. complex rules and regulations give rise to simple, stupid behavior;” an Agile culture exemplifies this spirit. In this new world, the bywords are collaboration and rapid adaptability. Customer-developer interaction (a big taboo in the tightly controlled waterfall world) is encouraged, delivery of working code is emphasized over technical documents, and even 11th hour changes to requirements are par for the course.
Unsurprisingly, not all organizations have welcomed Agile methods with open arms. Some have characterized it as “cowboy coding” and are reluctant to deviate from their own highly codified and disciplined methodologies. But the stereotype that Agile equates to a lack of discipline or planning are beginning to fade. As current economic circumstances force companies to reassess the business value of complex and burdensome project management methods, more organizations are turning to Scrum, XP or Agile UP. A track record of success stretching back over a decade helps to convince the doubters.
IT projects that have fully fleshed out requirements up front are a rare exception, but too many organizations still run projects based on this premise. Agile methods simply recognize the reality that customers can change their minds. Concepts such as “scope creep” or “requirements churn,” the bane of the waterfall world, no longer have any meaning in this new context. And when working software is the primary measure of progress, what’s not to like?
Monday, January 12, 2009
Do You Trust Me?
Trust. No team can function without it. As a PM stepping into a new project you'll have to work to earn it.
Where to begin? By setting an early precedent that you are reliable and can keep commitments. Within the first 24 hours you need to be demonstrating that you deliver on promises. This can be as simple as adding people who need to charge time to the project into the billing program, or emailing requested documents. The point is to communicate right away that you follow through on commitments.
Imagine the alternative. Let's say you've made a loan to a friend, where they promise to pay you back in installments on the first of each month. Then the first payment date arrives, and …..nothing. Perhaps they just plain forgot and you get the check a few days later. Even if they make the next few payments on time, in the back of your mind, that first impression of unreliability still lingers. Whenever the first of the month arrives, you will still have some doubts about whether or not the check will show up.
A project manager can cement their trustworthiness by reversing this psychology. Reply immediately to emails and voice mails from your project team members. Jump on any problems and make the team aware that you are escalating them or digging for information. Distribute detailed meeting minutes that show you have invested time to get fully up to speed on the project's technology, issues, and action items. And do everything visibly. The message you are sending to the team is that you care, you are responsive, and you can clear roadblocks.
The ultimate goal is not just an environment where everybody trusts YOU, but a team culture where everyone keeps their commitments to each other. So after you've set this precedent, you need to maintain and expand it. Creating more interim delivery dates (mini-milestones,) for example, provides additional opportunity to demonstrate reliability. And publicly recognizing and reinforcing compliance with these delivery dates communicates the priority you give to them.
Lack of trust on a project can result in team members who won't share information, withdraw effort or just do the minimum, or discount others' contributions. And when a team doesn't trust their project manager, delivering a successful project is nearly impossible. Prove your reliability as quickly and publicly as possible and you are off to a great start. Reinforce the importance of reliability among the entire team and you foster a culture of commitment.
Where to begin? By setting an early precedent that you are reliable and can keep commitments. Within the first 24 hours you need to be demonstrating that you deliver on promises. This can be as simple as adding people who need to charge time to the project into the billing program, or emailing requested documents. The point is to communicate right away that you follow through on commitments.
Imagine the alternative. Let's say you've made a loan to a friend, where they promise to pay you back in installments on the first of each month. Then the first payment date arrives, and …..nothing. Perhaps they just plain forgot and you get the check a few days later. Even if they make the next few payments on time, in the back of your mind, that first impression of unreliability still lingers. Whenever the first of the month arrives, you will still have some doubts about whether or not the check will show up.
A project manager can cement their trustworthiness by reversing this psychology. Reply immediately to emails and voice mails from your project team members. Jump on any problems and make the team aware that you are escalating them or digging for information. Distribute detailed meeting minutes that show you have invested time to get fully up to speed on the project's technology, issues, and action items. And do everything visibly. The message you are sending to the team is that you care, you are responsive, and you can clear roadblocks.
The ultimate goal is not just an environment where everybody trusts YOU, but a team culture where everyone keeps their commitments to each other. So after you've set this precedent, you need to maintain and expand it. Creating more interim delivery dates (mini-milestones,) for example, provides additional opportunity to demonstrate reliability. And publicly recognizing and reinforcing compliance with these delivery dates communicates the priority you give to them.
Lack of trust on a project can result in team members who won't share information, withdraw effort or just do the minimum, or discount others' contributions. And when a team doesn't trust their project manager, delivering a successful project is nearly impossible. Prove your reliability as quickly and publicly as possible and you are off to a great start. Reinforce the importance of reliability among the entire team and you foster a culture of commitment.
Sunday, January 11, 2009
In English, Please?
One project management skill group you won’t see called out on the PMP exam is "Translating." By that I mean being able to render TechSpeak to ExecSpeak and vice versa. PMs need to rapidly switch gears depending on their audience in order to explain the same situation in utterly different ways.
Let’s start with business requirements. From the perspective of the developers, architects and testers on your team, the statement of work or requirements document that your customer hands down might seem preposterously vague. “Improve processing time?” “Create a better user experience?” “Build a more reliable environment?” What does any of this mean? How is it quantified? What is the success criteria?
The project manager’s response might be to facilitate a requirements clarification session with the technical leads and the customer, serving as a translator/negotiator to help break down each requirement. Listening, rephrasing, and explaining are the crucial skills (“so what I hear you saying ….”) Through this process, “improve processing time” evolves to “be able to process a minimum of 1000 transactions per minute” and eventually to a detailed set of system changes needed to support this requirement (and finally to a task-level work breakdown structure with dates and deliverables.)
The communication gap can also arise when trying to explain a problem. For example, if development hits a snag, the response from the coder working on the problem can be an endless stream of alphabet soup describing failed job names or mismatched database fields or misaligned middleware scheduler entries. The project manager’s mandate is to distill all of this into a concise “elevator speech” for their client (ie, “the data isn’t showing up correctly because of a problem with the interface to the upstream system; we’re targeting a fix for tomorrow.”) If they want more details, be prepared to explain in more depth. But often times, especially with senior level execs, an assurance that you’ve identified the problem and will solve it quickly is sufficient.
The information needs of executive customers and technical project team members will differ greatly by organization. For example, you may be lucky enough to have a customer with whom you can talk the language of field formats and DNS entries (at my own job, this is often the case) but don’t bank on it. Mastering Exec to Tech translation skills should be high on the agenda for anyone in project management.
Let’s start with business requirements. From the perspective of the developers, architects and testers on your team, the statement of work or requirements document that your customer hands down might seem preposterously vague. “Improve processing time?” “Create a better user experience?” “Build a more reliable environment?” What does any of this mean? How is it quantified? What is the success criteria?
The project manager’s response might be to facilitate a requirements clarification session with the technical leads and the customer, serving as a translator/negotiator to help break down each requirement. Listening, rephrasing, and explaining are the crucial skills (“so what I hear you saying ….”) Through this process, “improve processing time” evolves to “be able to process a minimum of 1000 transactions per minute” and eventually to a detailed set of system changes needed to support this requirement (and finally to a task-level work breakdown structure with dates and deliverables.)
The communication gap can also arise when trying to explain a problem. For example, if development hits a snag, the response from the coder working on the problem can be an endless stream of alphabet soup describing failed job names or mismatched database fields or misaligned middleware scheduler entries. The project manager’s mandate is to distill all of this into a concise “elevator speech” for their client (ie, “the data isn’t showing up correctly because of a problem with the interface to the upstream system; we’re targeting a fix for tomorrow.”) If they want more details, be prepared to explain in more depth. But often times, especially with senior level execs, an assurance that you’ve identified the problem and will solve it quickly is sufficient.
The information needs of executive customers and technical project team members will differ greatly by organization. For example, you may be lucky enough to have a customer with whom you can talk the language of field formats and DNS entries (at my own job, this is often the case) but don’t bank on it. Mastering Exec to Tech translation skills should be high on the agenda for anyone in project management.
Friday, January 9, 2009
Executives In Training?
Can a project management career path eventually lead to the corner office? From what I've seen in my own organization, PM experience is more highly valued than ever when it comes to climbing the corporate ladder. And technical skills have little to do with this.
To begin with, project managers can get a fantastic strategic perspective by working across the length and breadth of their organizations. No silos for US. You may be a technology PM, but your projects can immerse you into the arcane worlds of marketing, supply chains, procurement, human resources, facilities, vendor management, and legal contracting. Every time you design an IT solution for a business, you learn a surprising amount about how that business operates.
The next advantage flows from a project manager's basic talents. The negotiating, influencing, planning, risk management, and budgeting abilities required to deliver complex projects mirror an executive skillset. In an article in The International Journal of Project Management, Linda S. Henderson observed that "projects are incubators for the development of future leaders. Experience on project teams often tests a wide variety of skills and behaviors." None other than Harold Kerzner concurred, noting that "project managers already consider themselves to be executives on the project, and naturally expect their next steps to be as executives in the company." More evidence is provided by CIO Insight magazine, which surveyed thousands of IT executives in 2006 and found that 82% of CIOs had been project managers at one point in their careers.
Those project managers with superior interpersonal skills, however, may have the decisive advantage. The aptitude to manage conflict, instill trust and team unity, sense and address unspoken emotions, ask incisive questions, please clients, work across international borders, and solve problems collaboratively is vital at the next level. Catherine Daw notes in her article Turning Successful Project Managers Into the Executive Leaders of Tomorrow, for example, that "the ability to influence, motivate team members, and achieve significant project results through a team are all key skills that successful project managers have and executive leaders require."
Daw also observed that while project managers often enter the field due to their technical abilities, they are quickly called upon to display executive behavior such as "more clearly understanding the corporate objectives; gauging the big picture; dealing with executives as sponsors and being able to draw teams from disparate departments and geographies together to deliver specific business results." While technical skills remain important to simply getting the job done, the interpersonal and leadership abilities demanded of project managers are truly essential for moving up the career ladder.
In some sense, as Kerzner noted, project managers are already executives. Every cross-functional project is like a mini-organization. No surprise to me that project managers are finally getting rewarded and promoted for what they've been doing all along: successfully leading people toward a common goal.
To begin with, project managers can get a fantastic strategic perspective by working across the length and breadth of their organizations. No silos for US. You may be a technology PM, but your projects can immerse you into the arcane worlds of marketing, supply chains, procurement, human resources, facilities, vendor management, and legal contracting. Every time you design an IT solution for a business, you learn a surprising amount about how that business operates.
The next advantage flows from a project manager's basic talents. The negotiating, influencing, planning, risk management, and budgeting abilities required to deliver complex projects mirror an executive skillset. In an article in The International Journal of Project Management, Linda S. Henderson observed that "projects are incubators for the development of future leaders. Experience on project teams often tests a wide variety of skills and behaviors." None other than Harold Kerzner concurred, noting that "project managers already consider themselves to be executives on the project, and naturally expect their next steps to be as executives in the company." More evidence is provided by CIO Insight magazine, which surveyed thousands of IT executives in 2006 and found that 82% of CIOs had been project managers at one point in their careers.
Those project managers with superior interpersonal skills, however, may have the decisive advantage. The aptitude to manage conflict, instill trust and team unity, sense and address unspoken emotions, ask incisive questions, please clients, work across international borders, and solve problems collaboratively is vital at the next level. Catherine Daw notes in her article Turning Successful Project Managers Into the Executive Leaders of Tomorrow, for example, that "the ability to influence, motivate team members, and achieve significant project results through a team are all key skills that successful project managers have and executive leaders require."
Daw also observed that while project managers often enter the field due to their technical abilities, they are quickly called upon to display executive behavior such as "more clearly understanding the corporate objectives; gauging the big picture; dealing with executives as sponsors and being able to draw teams from disparate departments and geographies together to deliver specific business results." While technical skills remain important to simply getting the job done, the interpersonal and leadership abilities demanded of project managers are truly essential for moving up the career ladder.
In some sense, as Kerzner noted, project managers are already executives. Every cross-functional project is like a mini-organization. No surprise to me that project managers are finally getting rewarded and promoted for what they've been doing all along: successfully leading people toward a common goal.
Thursday, January 8, 2009
There Is No Such Thing as an IT Project
You've probably heard this one before. There truly are no "IT Projects" - only business requirements that have IT solutions. A good project manager keeps steering their team back toward this principle.
What's the alternative? To paraphrase another cliché, when you're an IT hammer, everything looks like a technical nail. For example, on my current project, the infrastructure leads are telling me it will take nine consecutive weekends of outages to migrate from one application environment to another. This for a service where the customer throws a fit if we are down for maintenance for only a few occasional hours. In other words, these guys are working with their technical blinders on. The customer's needs aren't part of their equation, only their ideal, methodical infrastructure migration plan.
This is the kind of situation where an experienced and creative PM earns their paycheck, asking questions like:
• Does everything need to be sequential? What tasks can be overlapped?
• What constitutes the minimum scope for getting the service up and running? What are the "nice-to-haves" on the task list that we can consider deferring?
• Is an outage truly required? Can we run the service from Server A while updating Server B on the same cluster and switch over, vice versa?
• How much can we do between maintenance windows? Does everything HAVE to be done during a service outage?
• How did you come up with the time frames for each task? What is this based on?
• If we pull in more resources, will this help or make everything more unwieldy?
• Does this long timeframe has to do with the way that the service is currently architected, and what can we do to make it easier to migrate in the future?
And so on. The point is that the PM's role is to keep customer sensitivities and interests front and center when evaluating their team's recommended approaches. In situations like this one, where the proposed solution will simply never fly with the business side, you have to push back. Get everyone in a room and ask probing questions, get a dialogue going, force them to think outside their usual comfortable pattern.
For example, if you've seen the Tom Hanks movie "Apollo 13," you might remember the scene where the NASA engineers on the ground have only a few hours to figure out how to maintain the capsule's oxygen supply, given a very narrow set of materials. The final solution, I recall, involved the use of duct tape. Hardly part of NASA's standard methodology, but their customers in orbit weren't able to wait for the perfect technical solution.
Almost every PM will have a day like this one at some point. A moment where the clock is ticking and you're frantically trying to facilitate a compromise solution like NASA's duct taped hardware. Where ploughing ahead with the standard nine weekends of service outages simply isn't an option, no matter how happy your technical team would be to do so. All in the name of meeting your customer's legitimate business needs. Embrace these moments. These are the experiences that will serve you well in every future effort.
What's the alternative? To paraphrase another cliché, when you're an IT hammer, everything looks like a technical nail. For example, on my current project, the infrastructure leads are telling me it will take nine consecutive weekends of outages to migrate from one application environment to another. This for a service where the customer throws a fit if we are down for maintenance for only a few occasional hours. In other words, these guys are working with their technical blinders on. The customer's needs aren't part of their equation, only their ideal, methodical infrastructure migration plan.
This is the kind of situation where an experienced and creative PM earns their paycheck, asking questions like:
• Does everything need to be sequential? What tasks can be overlapped?
• What constitutes the minimum scope for getting the service up and running? What are the "nice-to-haves" on the task list that we can consider deferring?
• Is an outage truly required? Can we run the service from Server A while updating Server B on the same cluster and switch over, vice versa?
• How much can we do between maintenance windows? Does everything HAVE to be done during a service outage?
• How did you come up with the time frames for each task? What is this based on?
• If we pull in more resources, will this help or make everything more unwieldy?
• Does this long timeframe has to do with the way that the service is currently architected, and what can we do to make it easier to migrate in the future?
And so on. The point is that the PM's role is to keep customer sensitivities and interests front and center when evaluating their team's recommended approaches. In situations like this one, where the proposed solution will simply never fly with the business side, you have to push back. Get everyone in a room and ask probing questions, get a dialogue going, force them to think outside their usual comfortable pattern.
For example, if you've seen the Tom Hanks movie "Apollo 13," you might remember the scene where the NASA engineers on the ground have only a few hours to figure out how to maintain the capsule's oxygen supply, given a very narrow set of materials. The final solution, I recall, involved the use of duct tape. Hardly part of NASA's standard methodology, but their customers in orbit weren't able to wait for the perfect technical solution.
Almost every PM will have a day like this one at some point. A moment where the clock is ticking and you're frantically trying to facilitate a compromise solution like NASA's duct taped hardware. Where ploughing ahead with the standard nine weekends of service outages simply isn't an option, no matter how happy your technical team would be to do so. All in the name of meeting your customer's legitimate business needs. Embrace these moments. These are the experiences that will serve you well in every future effort.
Tuesday, January 6, 2009
How Technical Does a PM Have To Be?
Ever volunteer to speak at a school "career day?" Try this some time if you want to test your presentation skills in front of a demanding audience. These events feature everyone from chefs to cops, all of whom try and explain their job routines to 7th and 8th graders. Trying to engage these kids with a discussion of IT project management can be a tough sell.
My approach was to lead off with a slide showing a firefighter, a baseball umpire, and a symphony conductor. I would then explain how a PM's day was a mix of troubleshooting, coordinating, and mediating. But the conductor, I would add, is the best metaphor for the job. You don't necessarily need to know how to play the violin or the trombone. But you have to make sure everyone is playing the right notes and at the right pace, for starters.
In retrospect, I should have added more to this. The conductor who can grab the bow and nail Shostakovich's Violin Concerto No. 1 is indeed a rarity. There are still certain expectations, however, for the guy who waves the little stick. Conductors need to know the technical terms that the violinist uses (which are different from those of the cellist or trombonist), proper bow and finger placement, perhaps even the application of the Suzuki method and how often to apply bow rosin.
And so it is in the IT world. Never wrote a line of code, set up a server, or designed a user interface? Well you can still be an excellent project manager, even if you've never programmed anything more complex than a VCR. You simply need to have a base level of knowledge that can give you credibility with the team and allow you to make informed decisions.
Your credibility begins with simply getting things done for the project team. If you can successfully escalate issues, drag in needed new resources or information, and smash through bureaucratic logjams, you can win respect from most. But dedication and problem solving is only half the equation. You also need to speak the language of whatever architecture/technology/domain you are working with, know the common issues and risks, understand requirements and design docs, and be able to diagram the workflows and how the pieces fit together.
The depth to which you need to know all this may depend on the size and complexity of your project. In larger projects you'll probably have lead designers and architects to lean on, for example. But the one constant is that you will often need to mediate team debates over technical approaches, and explain to your boss the pros and cons of each angle. You'll have to write cogent minutes and other communications that accurately reflect technical decisions and issues. You'll need to identify when a design approach may have upstream or downstream system impacts (this is crucial, since your team members may only be thinking of their own application realm, not the big picture....that's YOUR job.)
Over time and through osmosis, you may learn just enough to be dangerous.
My approach was to lead off with a slide showing a firefighter, a baseball umpire, and a symphony conductor. I would then explain how a PM's day was a mix of troubleshooting, coordinating, and mediating. But the conductor, I would add, is the best metaphor for the job. You don't necessarily need to know how to play the violin or the trombone. But you have to make sure everyone is playing the right notes and at the right pace, for starters.
In retrospect, I should have added more to this. The conductor who can grab the bow and nail Shostakovich's Violin Concerto No. 1 is indeed a rarity. There are still certain expectations, however, for the guy who waves the little stick. Conductors need to know the technical terms that the violinist uses (which are different from those of the cellist or trombonist), proper bow and finger placement, perhaps even the application of the Suzuki method and how often to apply bow rosin.
And so it is in the IT world. Never wrote a line of code, set up a server, or designed a user interface? Well you can still be an excellent project manager, even if you've never programmed anything more complex than a VCR. You simply need to have a base level of knowledge that can give you credibility with the team and allow you to make informed decisions.
Your credibility begins with simply getting things done for the project team. If you can successfully escalate issues, drag in needed new resources or information, and smash through bureaucratic logjams, you can win respect from most. But dedication and problem solving is only half the equation. You also need to speak the language of whatever architecture/technology/domain you are working with, know the common issues and risks, understand requirements and design docs, and be able to diagram the workflows and how the pieces fit together.
The depth to which you need to know all this may depend on the size and complexity of your project. In larger projects you'll probably have lead designers and architects to lean on, for example. But the one constant is that you will often need to mediate team debates over technical approaches, and explain to your boss the pros and cons of each angle. You'll have to write cogent minutes and other communications that accurately reflect technical decisions and issues. You'll need to identify when a design approach may have upstream or downstream system impacts (this is crucial, since your team members may only be thinking of their own application realm, not the big picture....that's YOUR job.)
Over time and through osmosis, you may learn just enough to be dangerous.
Sunday, January 4, 2009
So, You Want To Be A Project Manager?
You’re not alone. The past few years have seen an explosive growth of new PMP (Project Management Professional) certifications. According to Allan Hoffman at Monster.com, there are now about 181,000 certified PMPs, 12,000 of them in IT.
I’ve lost count of all the developers, testers, and even product managers at my company who have asked my advice on how to make the switch to a technology project management career. Outside of work I get these questions as well. One oblivious friend of mine actually lectured me on how easy the job must be, since all PMs seem to do is make schedules and set up meetings.
Really? Who knew.
I’ve been an Information Technology project manager for twelve years. I work at a large corporation in the San Francisco Bay Area which I’ll keep anonymous for obvious reasons. In 2001 I earned my PMP and two years ago I completed my MBA. As a director-level PM in my current organization I’ve managed projects with budgets up to $17 million, usually several at a time.
I like my job, and here’s why:
• The constant variety. No two days at work are the same. Rarely are any two projects the same, at least in my world.
• The mix of left and right brained skills required. Emotional intelligence and savvy negotiation ability are as important as your capacity for financial and technical analysis.
• A sense of completion and accomplishment. Once your project is wrapped and your customer is happily using their new application, network or hardware, it’s a great feeling. For operational managers, such moments can be rare (trust me on this, I used to manage an accounting department.) A project manager in my company closes a project every six to twelve months.
• Education. Every day at work is like being in technology school. Projects are fantastic opportunities to learn through osmosis. It’s unavoidable. As an undergraduate liberal arts major, I never took a single programming class, but today I can actually have an intelligent conversation about data warehouse architecture or middleware configuration or business intelligence system design. Who would have thought?
• (I’m also fortunate to work with people I like, and a boss who trusts me to get things done. These two factors certainly make life much easier.)
But as to my friend’s comment about project management being a picnic, I respectfully disagree. For starters,
• You have Responsibility without Authority. In a matrix organization, which most big corporations seem to embrace, a project manager doesn’t have any direct reports. People are “borrowed” from other departments (development, QA, documentation, hardware, etc.) for the duration of the effort. They may be working on several project simultaneously, and you may find yourself horse trading with their manager for their time. The loyalty of your project team could be stretched in a half dozen different directions.
• You’d better enjoy being a control freak. If the guy in Singapore who was supposed to test the firewall ports for your server never followed through, look in the mirror if you want to blame someone. You should have known to have someone follow up on HIM.
• IT PM’s spend a big chunk of time firefighting. Especially when you’re working with new technology, be prepared for thorny system issues that have your developers scratching their heads while the customer screams about the delays. You better have the salesmanship (and internal network) to escalate these issues quickly and get enough resources on the problem.
• In many organizations with a mature PM structure, management puts as much stress on complying with paperwork and methodology as on successful project delivery. You’d best make sure your presentations are formatted correctly, that the right documents are in the right folder in your sharepoint directory, that customer signoffs are property documented. If all this sounds too trivial, controlling or exasperating for you, then you might want to consider another line of work.
• Scope creep, shrinking budgets, resource contention … the bread and butter of a PM’s day. Especially in this fun era of layoffs and cutbacks.
That’s just a taste of it. The purpose of this blog is to give those of you who are considering making the switch to a project management career some insider advice about life in the PM trenches. So we’ll dive deeper into these issues and more in posts to come. Feel free to email me with questions or topics and I’ll be glad to give you my perspective.
IT project management can be an immensely rewarding career if you have the right mindset and are well prepared for the inevitable headaches. Hopefully I can help you decide if it’s the right career for you.
I’ve lost count of all the developers, testers, and even product managers at my company who have asked my advice on how to make the switch to a technology project management career. Outside of work I get these questions as well. One oblivious friend of mine actually lectured me on how easy the job must be, since all PMs seem to do is make schedules and set up meetings.
Really? Who knew.
I’ve been an Information Technology project manager for twelve years. I work at a large corporation in the San Francisco Bay Area which I’ll keep anonymous for obvious reasons. In 2001 I earned my PMP and two years ago I completed my MBA. As a director-level PM in my current organization I’ve managed projects with budgets up to $17 million, usually several at a time.
I like my job, and here’s why:
• The constant variety. No two days at work are the same. Rarely are any two projects the same, at least in my world.
• The mix of left and right brained skills required. Emotional intelligence and savvy negotiation ability are as important as your capacity for financial and technical analysis.
• A sense of completion and accomplishment. Once your project is wrapped and your customer is happily using their new application, network or hardware, it’s a great feeling. For operational managers, such moments can be rare (trust me on this, I used to manage an accounting department.) A project manager in my company closes a project every six to twelve months.
• Education. Every day at work is like being in technology school. Projects are fantastic opportunities to learn through osmosis. It’s unavoidable. As an undergraduate liberal arts major, I never took a single programming class, but today I can actually have an intelligent conversation about data warehouse architecture or middleware configuration or business intelligence system design. Who would have thought?
• (I’m also fortunate to work with people I like, and a boss who trusts me to get things done. These two factors certainly make life much easier.)
But as to my friend’s comment about project management being a picnic, I respectfully disagree. For starters,
• You have Responsibility without Authority. In a matrix organization, which most big corporations seem to embrace, a project manager doesn’t have any direct reports. People are “borrowed” from other departments (development, QA, documentation, hardware, etc.) for the duration of the effort. They may be working on several project simultaneously, and you may find yourself horse trading with their manager for their time. The loyalty of your project team could be stretched in a half dozen different directions.
• You’d better enjoy being a control freak. If the guy in Singapore who was supposed to test the firewall ports for your server never followed through, look in the mirror if you want to blame someone. You should have known to have someone follow up on HIM.
• IT PM’s spend a big chunk of time firefighting. Especially when you’re working with new technology, be prepared for thorny system issues that have your developers scratching their heads while the customer screams about the delays. You better have the salesmanship (and internal network) to escalate these issues quickly and get enough resources on the problem.
• In many organizations with a mature PM structure, management puts as much stress on complying with paperwork and methodology as on successful project delivery. You’d best make sure your presentations are formatted correctly, that the right documents are in the right folder in your sharepoint directory, that customer signoffs are property documented. If all this sounds too trivial, controlling or exasperating for you, then you might want to consider another line of work.
• Scope creep, shrinking budgets, resource contention … the bread and butter of a PM’s day. Especially in this fun era of layoffs and cutbacks.
That’s just a taste of it. The purpose of this blog is to give those of you who are considering making the switch to a project management career some insider advice about life in the PM trenches. So we’ll dive deeper into these issues and more in posts to come. Feel free to email me with questions or topics and I’ll be glad to give you my perspective.
IT project management can be an immensely rewarding career if you have the right mindset and are well prepared for the inevitable headaches. Hopefully I can help you decide if it’s the right career for you.
Subscribe to:
Posts (Atom)
