Skip to main content

Author: Yogi Schulz

Do You Know Where Your IT Projects Are? Part 4.

Written by Yogi Schulz on . Posted in Articles. 4 Comments on Do You Know Where Your IT Projects Are? Part 4.

In this last of four articles, Yogi Schulz completes his description of the 12 signs of impending IT project doom that are visible months before catastrophe strikes.

Change Management

Good – I lead the project team in addressing the introduction of new business processes and their impact on staff.  For example, the project team has been coaching business leaders in how to introduce and effect the required change to the order fulfillment process.

Bad – The project team is not introducing new business processes, despite my encouragement as project manager, to place more emphasis on this topic.  For example, the project team is totally absorbed in software development and data migration.  No resources and capacity are available to think about how the new system will change long-standing business processes.

Ugly – The project team doesn’t believe change management is required.  The project team believes change management will be handled informally by the business and is not part of the project scope.  For example, because the project team does not include individuals with the requisite change management experience, the team has rather flippantly said to the business:  You handle the change management piece.

The Fix

  • Recognize that almost every IT project introduces business process changes.
  • Insist that change management is in scope for the project to help the organization make the change.
  • Successful project managers ensure the project team competently executes change management tasks.

Project Technology

Good – The project consistently uses a short list of technologies.  I can conceptually describe the technology.  For example, the technology being used is .NET and SQL*Server.

Bad – The project uses an extensive and changing list of technologies.  Initially it was Microsoft; some months later it’s Java and more recently something called LAMP is being discussed.  For example, the project changed from .NET/SQL*Server to LAMP claiming shorter software development times.

Ugly – I observe the project team using lots of technology buzzwords in discussions. It’s not clear what technologies the project is actually using.  I’ve seen a flashy demo but I’m not sure how that delivers business value.  For example, some of the project team is using Java for the database layer, others are using .NET for the application layer and a few are using PHP for the presentation layer.  It appears the developers are using the tools they’re most comfortable with or the tools they want to explore.

The Fix

  • Select and stay with a set of technologies for the project.  Avoid revisiting technology selection as new glitzy products are announced.
  • Pick technologies where the IT organization demonstrates expertise and experience.
  • Successful project managers assertively insist that project team members stick with the selected technology.

Conclusions

For each of the characteristics, watch out for the signs that lead to project catastrophe and take action to ensure project success.

Recommendations

Address Project Success Factors in the Project Charter

As project manager, describe how you expect to execute the project in the project charter for discussion with the project sponsor and other members of the project steering committee.  For example, describe your project organization, status reporting plan and technology.

Use the draft project charter to drive discussions within the project team and with various stakeholders to achieve consensus on these key success factors.

Recognize Common Project Factors that Lead to Success or Failure

As project manager, keep a sharp lookout for these project failure factors.  Encourage the project team to draw the emergence of a project failure factor to your attention.  For example, when a project steering committee member resigns and no evidence of action to replace that person is apparent, what do you do?  Make a recommendation to the project sponsor.

Take Corrective Action when a Project Failure Factor Looms

By taking corrective action when project failure factors loom, you are ensuring that your organization achieves business value from its investments in the IT project.  You will also avoid the destructive finger pointing that is a consequence of most unsuccessful IT projects.  For example, what do you do when your project sponsor is promoted, transferred or fired?  Do you just meander along on your own?  No, as project manager you recommend to the project steering committee who will be the interim project sponsor and who the potential candidates for a new project sponsor are.

Don’t forget to leave your comments below

Yogi Schulz is a partner at Corvelle Consulting.  The firm specializes in project management and information technology related management consulting. Mr. Schulz holds a B.Com. from The University of Calgary, is a member of CIPS and holds its ISP designation. He has presented at many conferences, writes for the Microsoft web site and appears on CBC’s Wild Rose Forum. Mr.Schulz can be reached at [email protected].

References:
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-1.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-2.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-3.html

Do You Know Where Your IT Projects Are? Part 3.

Written by Yogi Schulz on . Posted in Articles. 4 Comments on Do You Know Where Your IT Projects Are? Part 3.

In this third of four articles, Yogi Schulz describes 12 signs of impending IT project doom that are visible months before catastrophe strikes.

Project Organization

Good – I’ve created a reasonably clear organization chart.  Names and titles are shown.  The chart shows few empty boxes.  For example, I recognize many of the names on the org chart.

Bad – I’ve created more than one organization chart with many lines.  Some names or titles are missing.  The org charts show multiple empty boxes.  It’s not clear who does what.  For example, the org chart shows a number of crossing lines; there are lots of different colors whose meaning is not clear.

Ugly – I’m not clear who is on the project team.  Various part-timers, who belong to other departments or groups, appear to have some vague role on the project team.  Consultants hold most of the leadership positions.  For example, there’s no org chart, only a list of people, some with question marks beside their names.

The Fix

  • Create a project organization chart.  Find the people needed to position the project for success.
  • Define roles and responsibilities.  Empowerment is too often subverted in ways that allow individuals to run amuck with few tangible achievements.
  • The application of the virtual organization model can result in little or no progress.  Fill vacancies.  Too many vacancies hamper progress.
  • Successful project managers work hard to organize individuals into a well-functioning project team.

Project Resources

Good – Most individuals on the project organization chart are assigned full-time and are employees.  We are using contractors where needed but not too many.  For example, the project team includes individuals from the key departments that will be affected by the project.

Bad – More individuals are part-time or contract staff than are full-time employees.  We just don’t have enough full-time employees to spare.  For example, the project team includes part-time individuals from key departments who are still expected to fulfill their regular duties.  For example, the project team consists of about 80% contractors because key departments claim they can’t spare full-time employees.

Ugly – We’re using the virtual resource concept.  We rely on various individuals within the company and perhaps at various vendors to perform assigned project tasks when asked in additional to their regular duties.  For example, our small project team is making specific requirements gather assignments to knowledgeable individuals in key departments.  For example, our small project team is contracting knowledgeable individuals who work for various vendors to complete software design assignments

The Fix

  • Staff the project team with mostly full-time individuals.  Part-time staff, with divided loyalties, tends to be less productive.
  • Contain the number of contractors.  Too many contractors can cause a loss of focus on business priorities.
  • Try to minimize the geographic dispersion of the project team.  Geographic dispersion increases costs and reduces clarity of communication even with a unified communication system.
  • Successful project managers work hard to resource the project with as much expertise and experience as they can acquire.

Project Steering Committee

Good – I ensure that key business areas that will be affected by the project are represented on the project steering committee.  The committee meets every 4 to 6 weeks.  Meetings consist of a productive combination of project status reporting and issue resolution.  For example, the project manager presents a regular report, is questioned in detail about issues in ways that is supportive of the project manager’s efforts.

Bad – The committee doesn’t exist as far as I, as project manager, can tell.  The project team usurps management authority by making up the answers it wants on major issues that have organization-wide impacts.  For example, the project team makes up answers on product pricing and shipping options for the web site because its choices simplify the required code.

Ugly – Committee membership is unclear to me or meetings are sporadic and/or offer little content.  The role of the committee is not well-understood by the members of the committee.  There is conflict among committee members.  For example, at occasional meetings of the project steering committee, the project manager’s presentation is interrupted by a member of the committee laying blame for some problem on another member of the committee.

The Fix

  • Create a project steering committee.  Projects without steering committees to provide guidance and break through road blocks tend not to produce successful outcomes.  The mere existence of this committee forcefully tells the project team and other stakeholders that this project matters to the organization.
  • Ensure executives with sufficient authority are members of the project steering committee.  Senior management sometimes tries to delegate membership down too far in the organization.  This results in an ineffective committee.
  • Hold regular meetings.  Regular meetings with real examination of project issues improve the productivity and quality of project team performance.  Inexperienced project staff fears this approach because they think it makes them look ineffective.  More experienced staff recognize that they need the senior help to push through needed change and that their efforts will be recognized as valuable leadership.
  • Successful project managers lead the project steering committee meetings.

Stakeholder Communication

Good – I’ve ensured effective communication to the various stakeholders.  I’ve led efforts by the project team to enhance collaboration among stakeholders to achieve project success.  For example, I’ve seen the project team facilitate discussions between the materials receiving group and the manufacturing scheduling group to reduce bottlenecks.

Bad – The communication to the various stakeholders that I’ve witnessed is sporadic.  The project team is sending inconsistent, even contradictory messages.  Some stakeholders are communicating inconsistent messages about their involvement with and commitment to the project.  For example, the project team planned for newsletters.  The first one was excellent, the second one was good and now 6 months have gone by and we have yet to see issue #3.

Ugly – I’ve not observed effective communication to the various stakeholders.  The project team is unsure what to say or is not communicating anything for fear of offending someone.  Communication among stakeholders is tense, bordering on conflict.  For example, the project team made some useful suggestions for improving customer data quality in the CRM system.  However, the Sales Department saw these ideas as over-kill and was critical of the project team.  We haven’t heard much from the project team since then.

The Fix

  • Develop ideas for ramping up stakeholder communications.  Use e-mail, web sites, newsletters and town hall meetings.
  • Take steps to enhance collaboration among stakeholders, perhaps through workshops, to build consensus on goals and priorities.
  • Sometimes formally signed-off decision records and formally approved project deliverables are needed to convincingly demonstrate progress.
  • Successful project managers create a comprehensive stakeholder communications plan and execute it seriously.

Don’t forget to leave your comments below

Yogi Schulz is a partner at Corvelle Consulting.  The firm specializes in project management and information technology related management consulting. Mr. Schulz holds a B.Com. from The University of Calgary, is a member of CIPS and holds its ISP designation. He has presented at many conferences, writes for the Microsoft web site and appears on CBC’s Wild Rose Forum. Mr.Schulz can be reached at [email protected].

References:
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-1.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-2.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-4.html

Do You Know Where Your IT Projects Are? Part 2

Written by Yogi Schulz on . Posted in Articles. 4 Comments on Do You Know Where Your IT Projects Are? Part 2

DoYouKnowWhereIn this second of four articles, Yogi Schulz describes more of the 12 signs of impending IT project doom that are visible months before catastrophe strikes. 

Project Manager

To evaluate the state of project management, you as project manager, can perform a little candid self-assessment.

Good – You work as the full-time project manager.  You have the confidence of the project sponsor.  You have appropriate experience and hide nothing from management.  For example, on your last assignment, you led a successful CRM implementation.

Bad – You have insufficient experience given the project characteristics or have competing responsibilities.  Your track record is inadequate.  For example, the project manager just led a successful but simple MS Office upgrade project.  For example, the project manager just led a project to improve the time-keeping system that upset some groups.

Ugly – My project is being managed as a self-managed team.  Project management is divided among several individuals; no one is really in charge; I’m just a figure-head.  A self-managed team may be a wonderfully positive working environment but it rarely delivers much due to too much debate and no way to bring competing visions to a consensus.  For example, the project manager role is shared among the more experienced project team members; they make decisions by consensus that consumes an enormous effort for even the smallest decision

The Fix

Appoint an IT professional with a record of successful delivery as project manager.  For example, appoint the project manager who just completed a successful integration of the data from an acquisition.  Business professionals rarely have appropriate IT project management expertise.  For example, don’t appoint a capable manager in supply chain.

Successful project managers produce project management deliverables such as updated Gantt charts, project status reports or Issue analysis reports.

Project Benefits

Good – I can articulate the benefits.  The benefits are credible to me, as a project manager, and are credible to the management team.  For example, benefits include reducing the cost of new customer acquisition.

Bad – Perceptions about the reality of benefits vary.  No one, including the project team, has had time to quantify benefits.  For example, the benefits are vague like improved customer service.  For example, the benefits are in dispute:  Some groups challenge that the goal of reduced elapsed time through the manufacturing process is achievable.  It doesn’t matter whether or not you, as a project manager, agree with this point of view.  However, without some consensus, it’s difficult for the project team to know what to work on or what’s a priority.

Ugly – I don’t see anyone accountable for securing the benefits.  Ensuring that the benefits promoted at project inception will actually be realized is not receiving any attention.  For example, the project plan is dominated by software and computing infrastructure deliverables; not good.  Ensuring that business benefits of the associated CRM application will actually be realized is assumed but not ensured.

The Fix

Ask the project team to list the benefits.

Quantify benefits that can be quantified.  Knowing the benefits enables the project team to effectively make the many trade-offs that every project demands.  The absence of quantified benefits makes it difficult to know if a project should be approved in the first place.  For example, staff time savings or reduced time for customer interactions from better performing applications are benefits that can be measured and quantified.

Link intangible benefits to key organization goals.  Intangible benefits that can’t be linked convincingly to key organization goals are nice-to-have benefits that likely don’t deserve funding.  For example, the intangible benefit of a new website that contains more content and improved navigation improves the customer experience and enhances brand value.

Dubious projects need to be cancelled.  You can recognize dubious projects by the project team’s inability to create a compelling list of tangible and intangible benefits.  For example, proposed projects where it’s difficult to identify a project sponsor, where the benefits sound really vague or distant and where the size of the projects is difficult to estimate need to be cancelled before they soak up valuable resources.

Successful project managers lead the project team in producing benefits analysis deliverables.

Project Plan and Status

To evaluate the quality of the project plan and the status reporting, you as project manager can perform a little candid self-assessment.

Good – I’ve created the same summary Gantt chart, showing plan and progress on at least two occasions.  The project plan is based mostly on effort.  Small tasks have been rolled up into deliverables.  Reported issues are resolved.  For example, I recognize the tasks in the project plan where I know progress has occurred.

Bad – I’ve never produced a Gantt chart or no comparability exists among the Gantt Charts I’ve produced.  The project plan is based more on duration than effort.  The project plan includes generic resource names like programmer or analyst or infrastructure guy.  Few issues are reported; little attention is paid to issue resolution.  For example, from one month to the next, the project Gantt chart looks dramatically different.

Ugly – What’s a Gantt chart?  Do we need a project plan?  I believe everyone has a good, shared understanding of the project goal and scope.  For example, we measure progress by monitoring cumulative spending.

The Fix

Lead the project team in creating a detailed project plan.  A detailed project plan is one where:

  1. no task exceeds 40 hours of effort
  2. every task is assigned to a known person
  3. no task has more than one assigned resource
  4. major tasks are linked into a precedence chain

Use the project planning exercise to resolve the many scope and approach ambiguities that typically hover around a project and threaten to derail it.

Use a credible project management software package to manage the project plan; not Excel or Visio or PowerPoint.  Ensure that progress reports against the project plan be produced and presented to the steering committee monthly.

Successful project managers produce successively more accurate project plans and project status reports.

Project Budget and Status

To evaluate the quality of the project budget and the financial reporting, you as project manager can perform a little candid self-assessment.

Good – I lead the creation of the budget and produce to regular updates of variance and cumulative spending.  I create spending projections.  For example, the monthly spending amounts are reasonably on target.  The projected variance at completion fluctuates modestly from month to month.

Bad – Budget and spending amounts I’ve produced change over time.  Projected spending variance at completion fluctuates wildly from month to month.  For example, the project budget and monthly spending amounts vary a lot from month to month for unknown reasons.

Ugly – No budget has been proposed or approved to my knowledge.  Projected spending variance at completion is not calculated.  For example, we’re spending money as needed as we go along.

The Fix

Lead the project team to create a budget derived from the project plan.

Make sure the project budget contains the following items that are often left off:

  1. Contingency to recognize the risk of under-estimating.
  2. Allowance for change orders to recognize the likelihood that one or more change orders will arise during execution of the project.
  3. Estimate of end-user effort; typically not costed,

Produce monthly update reports showing cumulative spending variance against budget and projected cost at completion.

When the projected variance at completion increases significantly, it’s likely time to recognize that some change in project scope or project approach is occurring that needs to be documented in a change order for discussion with the project steering committee.

Successful project managers produce project budget and spending outlook reports.

Don’t forget to leave your comments below

Yogi Schulz is a partner at Corvelle Consulting.  The firm specializes in project management and information technology related management consulting. Mr. Schulz holds a B.Com. from The University of Calgary, is a member of CIPS and holds its ISP designation. He has presented at many conferences, writes for the Microsoft web site and appears on CBC’s Wild Rose Forum. Mr.Schulz can be reached at [email protected]

References:
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-1.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-3.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-4.html

Do You Know Where Your IT Projects Are? Part 1.

Written by Yogi Schulz on . Posted in Articles. 4 Comments on Do You Know Where Your IT Projects Are? Part 1.

In this four part series, Yogi Schulz describes 12 signs of impending IT project doom that are visible months before catastrophe strikes. 

Learn to recognize common project success or failure factors when they occur in your project.  If you aren’t aware of common success or failure factors, you won’t notice when they appear on


your project.  For example, if the project schedule is slipping a day or two each month, that may not be cause for concern.  However, if the rate of slippage is increasing, you might end up a month behind schedule within a year.  That slippage will definitely become a topic of great concern.

Build an understanding of corrective actions that work when a project failure factor looms.  For each success or failure factor, we’ll discuss corrective actions that can turn a looming failure factor into a success factor.  For example, if the project schedule is slipping, the corrective action may be to jettison some scope or to re-assign a few tasks to others.

Many factors can derail IT projects.  Analysis of successful and failed projects reveals that the 12 factors described in these articles are the most frequent contributors both to successful projects and to failed projects.

On unsuccessful projects, many of these factors were not recognized as important, not addressed, sloughed off as unimportant or swept aside as some administrative nicety that was seen as a distraction from “real” progress.  For example, why build a project plan?  That just consumes effort that is better applied to getting on with it.

On successful projects, most of these factors were addressed.  Typically how these factors will be addressed during the course of the project is described in the Project Charter document.  For example, there’s no point kicking off a project without a project sponsor in place who has credibility in the executive circle.

So, if you’re a project manager looking for a chance to bring that feeling of doubt about the likelihood of success of your IT project out in a constructive way, take a moment to think about these factors.  The factors are designed to uncover the specific type of difficulty your IT project may be experiencing.  If you just say to the project sponsor:  “I have this gnawing feeling that our project is not going well.”  That’s an unhelpful comment.  Worse, it communicates that you may not be a team player and that your negative views may undermine the project.

However, if you say to the project sponsor: “I believe that our project plan is weak in these areas.  As a result we are most likely under-estimating a few risks.  Here’s my recommendation about how to fix the problem.”  Now, you’re impressing the project sponsor.  Now, you’re providing early warning of a problem that could lead to disaster.  You’re providing ideas for how to fix the problem.  Now, the project sponsor will think: “I want to keep this guy around.  He’s a real team player who is adding value.”

Based on these ideas, you should be able to better describe various project problems and craft solutions that will avert disaster.

We’ll discuss the twelve common project success or failure factors and how to fix them for project success here and in future articles.

Project Goal

Good – I’ve led development of a crisp statement of the project goal.  Business goals are referenced.  For example, the goal of the project is to reduce the average customer wait time at the call center by one minute.

Bad – I’ve heard a lot of debate about goals and have heard various conflicting statements. Technology potential is referenced by some stakeholders.  For example, the goal of the project is to reduce customer wait time at the call center by introducing a cool, new, faster network to improve response time.

Ugly – I’m not sure what the goal is.  My effort to understand the goal or to achieve some consensus with other stakeholders has not been successful.  For example, the customer service manager thinks the goal is to increase customer satisfaction, the call center manager thinks the goal is to have every call answered before the third ring.

The Fix

Assemble the project team and facilitate a discussion to build a clear statement of the project goal in no more than two sentences; one sentence is better.  Using the SMART[1] framework to describe the goal is effective.  Often it’s useful to list a small number of objectives that support the goal.  For example, implement ERP may be the goal.  Related objectives might be about improving data quality or which ERP modules will be implemented or the sequence in which various business units or divisions will be implemented.

Have the project steering committee endorse the proposed project goal.  Endorsement by the steering committee achieves consensus within management about what the project is all about and what the steering committee really wants to achieve. 

Endorsement starts the process of building a shared understanding of what the project will achieve.  The understanding will be elaborated as the project progresses.  For example, it’s common for different vice presidents to have different perceptions of what the problems are or what the priorities for fixing them should be; One VP may want to start with manufacturing planning while another one wants to start with billing.

Successful project managers work hard to achieve a consensus on the project goal early in the project and then work to maintain that consensus.

Project Sponsor

Good – I know the senior executive, who is the project sponsor, by name.  I have confidence in that individual.  For example, the VP of Production is the project sponsor of the ERP implementation.

Bad – The role is diffused among multiple individuals.  I’m not sure who has been assigned to do what.  I’m not sure why there are multiple project sponsors.  For example, the VP of Production and the VP Finance are both project sponsors of the ERP implementation; both seem to defer to the other on decisions.

Ugly – There is no project sponsor or I don’t know who holds the role of project sponsor.  Sometimes organizations confuse the role of project sponsor and project manager. Sometimes organizations believe the two roles are synonymous.  For example, the VP who was project sponsor was head-hunted and is now gone; no replacement has been named even though a manager was promoted to the VP spot.

The Fix

Recommend appointment of the manager of the business area that has most to gain from the project as project sponsor.  This person becomes chairman of the project steering committee.  For example, the VP of Production is a good choice for project sponsor of an ERP implementation.  Because ERP typically crosses organizational boundaries, include other VPs on the steering committee.

Provide some orientation to the person to become effective in the role.  The role is to address major issues and support the project team; especially the project manager.  The role is not to be a figurehead for some overly ambitious project manager.  The role is not to become the scapegoat for some looming disaster.

Successful project managers work to build and maintain the relationship with the project sponsor.

[1] http://www.projectsmart.co.uk/smart-goals.html.  The acronym has a variety of meanings; I like this one:
S – specific
M – measurable
A – achievable
R – relevant & realistic
T – time-framed

Don’t forget to leave your comments below

Yogi Schulz is a partner at Corvelle Consulting.  The firm specializes in project management and information technology related management consulting. Mr. Schulz holds a B.Com. from The University of Calgary, is a member of CIPS and holds its ISP designation. He has presented at many conferences, writes for the Microsoft web site and appears on CBC’s Wild Rose Forum. Mr.Schulz can be reached at [email protected].

References:
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-2.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-3.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-4.html