Access

You are not currently logged in.

Login through your institution for access.

login

Log in to your personal account or through your institution.

50 Top IT Project Management Challenges

50 Top IT Project Management Challenges

PREMANAND DORAISWAMY
PREMI SHIV
Copyright Date: 2012
Published by: IT Governance Publishing
Pages: 120
Stable URL: http://www.jstor.org/stable/j.ctt5hh7mc
Find more content in these subjects:
  • Cite this Item
  • Book Info
    50 Top IT Project Management Challenges
    Book Description:

    This book offers a focused and concise summary of 50 challenges facing today’s IT project manager. The authors draw on years of practical experience (rather than classroom theory) to outline these challenges and offer useful tips and advice on how to deal with them. This book condenses into a handy summary much of the information and advice that can be found in project management related books and discussion forums. It is an ideal reference for anyone involved in IT project management, from professional service organisations (PSO) and project management offices (PMO).

    eISBN: 978-1-84928-342-7
    Subjects: Technology
    × Close Overlay

Table of Contents

Export Selected Citations
  1. Front Matter (pp. 1-4)
  2. ABOUT THE AUTHORS (pp. 5-5)
  3. ACKNOWLEDGEMENTS (pp. 5-5)
  4. Table of Contents (pp. 6-7)
  5. INTRODUCTION (pp. 8-8)

    As a continuation of Prem’s first book on IT project management, this book provides a brief introduction to the ‘classic top 50 IT project management challenges’ and includes some tips on managing these challenges. It will be very helpful to project support officers (PSOs), programme management officers (PMOs), junior project managers (PMs) and experienced PMs, as a quick reference guide. Tips and suggestions provided in this book are based on our day-to-day, on-the-job experience, and the majority of them are applicable universally.

    We would like to wish our readers all the best, and encourage them to reach out to us...

  6. CHALLENGE 1: UNCLEAR REQUIREMENTS (pp. 9-11)

    In a poll recently conducted by us in a recognised project management forum, the majority of the project managers acknowledged that unclear requirements are, without a doubt, a top challenge for their projects.

    Starting with vague requirements is like heading off on a journey without knowing your destination. You are dealing with the unknown.

    The common practice amongst us is that we just bow to pressure from senior management. We accept the ambiguous requirement specifications and proceed with our estimations. Eventually, those projects get delayed, costs are at least doubled, the client’s quality expectations are not met, and, in the...

  7. CHALLENGE 2: MISSED REQUIREMENT (pp. 12-13)

    Nothing is more challenging for a project manager than a situation where, after successful project go-live, users complain that there is a requirement gap in the final product. Missing a requirement causes bad press for the project and project manager, and can damage the reputation of the organisation. In addition, there is an extra cost to fix, or the requirement to include in the next release, due to the rework around coding and testing.

    Based on the criticality of the missed requirement, there could be a significant loss to the organisation in terms of business benefits.

    The following ideas can...

  8. CHALLENGE 3: DELAY IN DOCUMENT APPROVALS (pp. 14-15)

    In an average complex project, the number of deliverables/documents created should range from 50-100. It is a mammoth challenge to get all these deliverables organised, shared with reviewers, reworked based on review comments, approved by clients, and baselined in the document repository. If you have experience working in a matrix project organisation, then you will be aware that it is far more complex. The resources allocated to you might be shared, have different line managers, have their own priorities, or not be fully allocated to you. These are a few of the many challenges.

    Many project managers’ pet peeve is...

  9. CHALLENGE 4: SCOPE CREEP (pp. 16-17)

    Scope creep is one of the top five reasons why a project can fail. To define scope creep, let us consider a construction company which is building a house for a client, with a well-drafted plan. During the client’s visits to the house, new items keep getting added to the plan, for example, building a wardrobe, an extra sink, more power outlets than planned initially, etc. The engineer implements the changes without documenting them on the plan and, once the house is built, there are several issues faced by the construction company:

    The house layout in the plan, and what...

  10. CHALLENGE 5: UNCLEAR RISKS AND ISSUES (pp. 18-19)

    It is important for a project manager to track project issues, risks, assumptions and dependencies. Sometimes it is very challenging for a project manager to keep them up to date, as well as log them in the appropriate place. It is a very common problem to have the project issues and risks logged/reported interchangeably. As they are reported at a senior management level, it generally gets escalated, and if senior management find them wrong, it would not be well received.

    A ‘project issue’ is a concern, or request, raised by any stakeholder or team member, that needs to be addressed,...

  11. CHALLENGE 6: PROJECT INFRASTUCTURE ISSUES (pp. 20-21)

    Unavailability of the project environment is always a common challenge in terms of its impact on the delivery timescales. For a project development, test and pre-production environments are to be available during the development, testing and user acceptance testing (UAT) phases. The basic assumption of the project planning would be the availability of the environments. If the environment is not available, then there is no way that the particular impact phase could carry on.

    There are certain things that can minimise the impact of this challenge. Some of the following are examples.

    Back-up of the code, test data and configurations...

  12. CHALLENGE 7: SERVICE INTRODUCTION CHALLENGES (pp. 22-23)

    In the project life cycle, there will be a parallel track that is led by the Service Introduction Manager (SIM). The SIM will manage the activities to take the project into business as usual (BAU), and the team will do the production support and post-warranty support. In smaller organisations, the project manager will usually dual play the SI manager role, and part of the application development team will act as the application maintenance/support team. In this scenario, the SIM will face certain challenges in terms of clarity, on the kind of activities that are to be carried out. This chapter...

  13. CHALLENGE 8: UNDEFINED PROJECT DEPENDENCIES (pp. 24-25)

    Typical project dependencies are deliverables from other projects and programmes that your project requires in order to reach completion. Often these get overlooked, which is why it is vital that you research these thoroughly, and then list them in a project dependency log. This ensures that there is no confusion going forward.

    Project dependencies are two-fold, they can be inbound or outbound.

    Inbound dependencies are those you expect other projects to deliver. For example, if there is an infrastructure project which is going to deliver the production environment for your project so that you can go live, then it is...

  14. CHALLENGE 9: PROJECT METHODOLOGY (pp. 26-27)

    Without a doubt, a properly chosen and strictly followed methodology for managing a project, is the guarantee that the project will be accomplished on time, under budget and as per specification. Project management methodology (PMM) should be followed to avoid failure, and to reduce risks. It is one of the critical success factors, as well as the core competency of the management staff. A suitable PMM is the direct way to guide the project team through developing and implementing activities and tasks in well-defined phases of the project implementation life cycle.

    The popular PMMs widely followed are:

    PRINCE2®¹

    PMBOK®

    Six...

  15. CHALLENGE 10: HANDLING ESCALATION (pp. 28-31)

    As a project manager, you are required to manage escalations from all directions, while escalating issues within the project team, to resolve issues faster. This chapter provides guidelines, with examples, on how a team can use ‘escalation processes’ to raise project issues to higher authorities, for timely resolution. An escalation process ensures that the next level of management is informed (often within a specific period of time), in the case where the issue cannot be resolved at a lower level.

    Although a team should strive to resolve as many issues and conflicts internally as possible, some issues can be serious...

  16. CHALLENGE 11: TIME-DRIVEN PROJECTS (pp. 32-33)

    Some projects start with an end-date in mind, and irrespective of how complex the requirements are, project managers are given a mandate to deliver the project within those timescales. For example, when there is a project that has a go-live date just before Christmas, in order to leverage the Christmas festival season, the project manger has to ensure the project is completed before that deadline. It is a huge challenge for the project manager.

    The following project scheduling tips can help you manage this situation.

    As you have the end-date to start with, identify the effort required for each of...

  17. CHALLENGE 12: UNDEFINED ROLES AND RESPONSIBILITIES (pp. 34-35)

    Defining the roles and responsibilities of the project is critical for each member to understand their roles and work duties. The roles and responsibilities should expand to the internal and external stakeholders of the project (possibly at a high level). Defining the roles and responsibilities of team members will assist the project manager in bringing onboard the appropriate resource for that role, by evaluating their skill set and finding the right match.

    Undefined roles and responsibilities lead to possible gaps in coverage of vital project elements and possible overlap. The roles and responsibilities should cover the business side of the...

  18. CHALLENGE 13: POST-LIVE SUPPORT UNCOVERED (pp. 36-37)

    Before implementing your project, you should have a support plan in place, and have gained approval from your senior IT management, business, IT and application support teams.

    Once the project goes live, it will be in warranty support – ideally for four weeks. It is logical that immediately after the project go-live, users new to the system will raise a substantial number of queries and issues, and report numerous incidents. The project team will be best qualified to support the application during the initial weeks of go-live.

    Project warranty support will ensure the users get quick responses for the problems...

  19. CHALLENGE 14: PROJECT INFRASTRUCTURE DELIVERY DELAYED (pp. 38-39)

    The infrastructure requirements for your project are very critical and should be managed as a sub-project. You should have a critical inbound dependency on the delivery of your project infrastructure to the project’s appropriate phases. For example, the development environment should be ready and handed over to you in order for your team to start the development work on your project. Similarly, the testing, pre-production and production environments are to be ready for functional test, performance test and go-live.

    What will happen if your project environment delivery is delayed? Obviously your project timescales are going to be delayed. How can...

  20. CHALLENGE 15: UNCLEAR QUALITY CRITERIA (pp. 40-41)

    It is very important to have project go/no-go meetings prior to project go-live. The usual participants of this meeting are business stakeholders, the project manager, test manager, service introduction lead, application maintenance team, project control board and the PMO team. The meeting’s agenda would include the project manager sharing the results of testing (both functional and performance) and a go-around the table for acceptance for go-live. Several parameters will be considered prior to acceptance. For example, the business team will check the business readiness, training, SLA and service delivery model. Similarly, the application maintenance team will review details, such as...

  21. CHALLENGE 16: UNSTRUCTURED PROJECT COSTING (pp. 42-43)

    Every project incurs costs through hardware/software, resources, vendor, network bandwidth and telephone. Tracking a project’s costs is dependent on your organisation’s requirements. The common purpose of tracking costs is to ensure they are within the budgeted figure. For example, if a project is budgeted for $1,000 and the project is going to return the organisation $5,000, then the business benefits/return on investment (ROI) is $4,000. If the project costs are not tracked, and the actuals are now more than $5,000, then the ROI is negative, and no organisation will want to deliver that project. In such cases, actual project cost...

  22. CHALLENGE 17: RESOURCE UTILISATION (pp. 44-45)

    Overloading of resources is one of the potential challenges that impacts project delivery. It is where a resource is assigned more work than they have the capacity to complete. For example, a resource works an eight-hour day and is assigned two tasks, each worth eight hours of effort, and scheduled to occur on the same day, as shown below.

    As the resource cannot complete both tasks at the same time, a resource overallocation occurs.

    When overallocation of resources occurs in the project schedule, the project effort will remain the same, as the resources complete Task 1 and move on to...

  23. CHALLENGE 18: REVISION OF ESTIMATES AND TIMESCALES (pp. 46-47)

    Often we get caught in the catch-22 situation when it comes to revision of estimates and timescales of our project. We don’t know for sure if we should go to our client/management team with revised estimates/timescales, because they always expect us to deliver to the timescales as agreed at the beginning of the project. In some scenarios, we don’t have any forums, such as steering committee meetings, to go to with estimates/timescale changes. There are even scenarios where an organisation has no change management process and all changes are to be absorbed by the project team.

    Worst of all, at...

  24. CHALLENGE 19: VENDOR QUALITY ISSUES (pp. 48-49)

    Project quality is important, as no one will agree to buy/use a poor quality product. Good project quality management techniques are important to ensure that a project’s deliverables and end results meet, or exceed, the client’s expectations. It is important to monitor the project continuously to prevent misnomers and misinterpretations.

    Sometimes your project vendor might not be following the quality standards and might deliver a poor product. How can you manage this situation?

    As a project manager, you should define the quality standards to be used in the project. This definition will come from the stakeholders, beneficiaries and often from...

  25. CHALLENGE 20: WRONG ASSUMPTIONS (pp. 50-51)

    Most projects create a list of project assumptions at some point in time. These are typically documented at the start of the project and are filed in a project assumption’s log. Aside from helping to fill in certain sections of the project management plan (PMP), they are usually ignored. We shall explain their importance and the challenges you might face due to the wrong assumptions.

    By definition, a project assumption is something taken for granted. It is very important to make project assumptions that move ahead with the project phase. It is not practically possible to wait until all the...

  26. CHALLENGE 21: UNCLEAR BUSINESS ROLLOUT APPROACH (pp. 52-53)

    A project’s go-live can be classified as the IT go-live and the business go-live. By definition, IT go-live can be considered as the successful installation of the software, hardware and other components involved in the project deliverables. Post-installation, the system should be running without any issues, such as central processing unit (CPU) crash, memory crash, faults generated from the system, components crash and network crash.

    Business go-live can be considered as when the end-users start using the system, enter data into the system, process the data, generate output and generate reports. The rollout plan is typically considered mainly for the...

  27. CHALLENGE 22: PROJECT CANCELLATION (pp. 54-55)

    For a project manager, nothing is worse than a project getting cancelled. In this recession-hit world, businesses have become smarter and they take up projects which they believe in, and which have more ROI value. Hence, projects such as the ones which cause lot of delays and eat up all the business benefits; projects which regulate changes in pipeline; projects that are non-business critical and can be put on hold, are the candidates for cancellation.

    If this happens, there are certain things that need to be done promptly, and are very easily overlooked when procrastinating.

    The first thing to do...

  28. CHALLENGE 23: PROJECT OPERATIONAL ISSUES (pp. 56-57)

    As a project manager, you will have quite a few operational issues during the project life cycle. For example:

    Absence of a critical team member due to sickness or accident.

    Infrastructure environment crashed and no source code back-up available to restore.

    Test data lost.

    Network issues – connectivity to development environment is intermittent.

    Travel constraints for a particular team member when it is absolutely necessary for him/her to travel for some project requirements.

    On-site team/off-shore team conflicts.

    The impact of these issues ranges from very high to very low. Some project managers take a casual approach to these operational issues...

  29. CHALLENGE 24: UNDEFINED PROJECT CRITICAL PATH (pp. 58-59)

    If we were to carry out a study of the most frequently used/referred to terminology in project planning, then ‘critical path’ would be the winner. Critical path is the list of tasks which have no slack, such as the tasks which you cannot afford to delay. If it happens, then be aware that your project is slipping.

    It is project management’s best practice to have status reports on the critical path.

    In today’s world, projects are getting more interesting, and at the same time, more complex. This leads to countless activities/tasks that are to be carried out by global teams....

  30. CHALLENGE 25: TIME AND COST ISSUES (pp. 60-61)

    For various reasons, your project might not be delivered within time, and may cost more than the forecasted amount. It could be due to a change in requirements, design issues, more defects, service introduction challenges or unclear requirements. Such situations are more challenging for project managers to manage, as there will be pressure from the IS senior management, business sponsors and users.

    Do you have any other options which can minimise the impact and make the delivery within time/cost? If yes, first you need to consider that before letting the news out to the world.

    For example, your project might...

  31. CHALLENGE 26: OVERESTIMATION OF PROJECTS (pp. 62-63)

    Projects are always about costs and ROIs, and one of the major spotlights falls on estimates, and the process around approval of estimates. Be it the initial one submitted during the proposal stage, or the one for the changes received during the project life cycle estimates, they are always scrutinised. It takes a lot of persuasion, and more than a valid justification, to walk into a client’s office with a request for a change in estimates. Most times it will be rejected, and you will be asked to deliver lower costs and faster, even though the estimates submitted by you...

  32. CHALLENGE 27: UNMANAGEABLE PLAN (pp. 64-65)

    Once the milestone plan and project costs are known, inform the key decision makers and/or all stakeholders about your project, to gain approval.

    The upside is that management will then back you up to deliver the project within the agreed cost and time line.

    Once you have gained approval from senior IT management, you will need to baseline the plan. By doing so, you commit to the dates and cost of the project; any deviations from these will not be acceptable without further approval from IT management, via the change management process.

    The baseline plan is stored in the project...

  33. CHALLENGE 28: OVERSPENT PROJECTS (pp. 66-67)

    Assume you are taking over a project with little or no transition, since your counterpart left early. After running that project for a couple of weeks, you have to submit a financial report. You notice that your project is already over spent. Now you are in a fix, you cannot progress with the project before getting more budget from management. What you are supposed to do now?

    Having found out that your project has overspent, you should first discuss whether it is viable to continue with the project. Identify how over spent the project is, what business benefits are yet...

  34. CHALLENGE 29: VENDOR PAYMENT MILESTONE ISSUES (pp. 68-69)

    As part of the project’s financial management, a project manager is responsible for generating purchase orders for vendors and tracking the purchase order in terms of the invoice approval against a payment/delivery milestone.

    For example, if your project is small, where only one vendor is involved and there is only one invoice per month, then it is easy to control purchase orders and invoices raised. If there are more than 20 vendor companies involved, each may have more than 10 purchase orders, which translates to over 200 invoices every month. Tracking them then becomes tedious.

    In this situation, some vendors...

  35. CHALLENGE 30: POOR SOURCE CODE QUALITY (pp. 70-71)

    Defect identification is inevitable during functionality testing, even if there has been thorough unit testing during the development phase. Usually in test management, the test manager comes out with the test approach, scenarios, conditions, cases and scripts, to complete the functional testing of your project. Their test plan should cover all of the requirements that are agreed to be delivered. The test manager will plan several cycles of testing. Starting with a full suite of functional testing, followed by successive cycles of testing defects from previous cycles, along with regression testing of the existing functionality, to make sure the fix...

  36. CHALLENGE 31: PROCESS INTERFERENCE (pp. 72-73)

    A project management process is the process of planning, controlling, or execution of a project. A typical project management process will have the following phases:

    Project initiation

    Project planning

    Project execution

    Project control

    Project closure.

    Each phase is sub-divided into multiple steps, and each step will have an input and an output deliverable. The amount of deliverables created at each phase is different between organisations, core culture, project size and project nature.

    There is a school of thought that implementing a project management process is a waste of time, and the team is losing the productivity on better tasks, for...

  37. CHALLENGE 32: PROJECT COLOUR CODING (pp. 74-75)

    Project colour coding is sometimes considered to be the easiest challenge for a project manager, yet at the same time, this is the one which causes lots of problems to the project, as it gets escalated too soon.

    As you know, the project status is sometimes referred to as the RAG status which stands for red, amber and green. There are further complications for project managers in their status report as they use reddish amber and greenish amber.

    By definition, project status red means your project delivery is in danger. It has either overspent, missed the timescales, or is back...

  38. CHALLENGE 33: PROJECT GO-LIVE FAILURES (pp. 76-78)

    It is usually all hands on deck and full steam ahead on D-day. We are sure that most of us have experienced the overwhelming rush of adrenaline in our body when it comes to the project go-live date. It is when the system will be used by the business users. No matter how much testing we have carried out, we cannot explain the situation when the first user logs into the system and the system crashes causing a severity one outage, and a severely tense senior manager is swarming your desk, pushing you to fix the problem, and demanding a...

  39. CHALLENGE 34: PROJECT PROTOTYPE FAILURE (pp. 79-80)

    Project prototypes/demos are key deliverables to the client in projects where more user interactions are involved. For example, a mobility project, where the users will use their iPad/BlackBerry PlayBook to log-in and do some transactions.

    Demos will give the users the confidence/trust in the project team, and will help to build a solid working relationship.

    You don’t need to wait for the whole demo to be complete to understand what the users think, you can gauge their reactions inside the first 10 minutes of the presentation. If the demo is not to the point, or if they don’t see what...

  40. CHALLENGE 35: CRITICAL TEAM MEMBER ABSENCE (pp. 81-84)

    No matter how perfectly we plan, sometimes the worst things happen at unexpected times, right before the big show. IT is no exception.

    You plan a big release, or an intellectual proposal, counting on one of your best people in your team. You call a management meeting to present it, and even win the proposal, only to find out that your best person is no longer part of your company. They have just accepted an offer from your competitor, for better pay.

    Or be it a case where the deliverable is in a week. Your only developer who has mastered...

  41. CHALLENGE 36: INSUFFICIENT SCHEDULE INFORMATION (pp. 85-86)

    As you know, the project schedule lists the various project tasks, effort involved, duration, resources allocated, dependencies, and/or constraints. It is expected that you maintain the schedule as detailed, and as up to date as possible.

    It is a challenge to have the detailed project schedule/tasks information at the very beginning of the project, and it is a mistake of the project manager to build such a detailed project schedule from the very beginning of the project.

    Typically, an average complex project will take three to six months from start to finish. You cannot plan the detailed activities and its...

  42. CHALLENGE 37: INSUFFICIENT DOMAIN KNOWLEDGE (pp. 87-88)

    Should a project manager be a subject matter expert (SME) in the domain of their project?

    This is an interesting discussion, with two schools of thought. One group suggests that if a project manager is not skilled enough in the domain/technology of their project, they will not have a sense of control in the project, they cannot add value, they might not be able to claim respect from their team, and they will be ineffective in handling challenges within the team, or from clients.

    Another group suggests that the project manager is responsible for the project delivery and they should...

  43. CHALLENGE 38: INSUFFICIENT TECHNICAL KNOWLEDGE (pp. 89-91)

    IT has evolved a lot in recent years, and one of the major trends to come out of this, is that people from all educational backgrounds have migrated to computers and related opportunities. People intending to change career paths, either for higher remuneration or better intellectual opportunities, join the bandwagon. The major roadblocks that this creates are that the person is not able to validate the estimates provided, they get left out on the technical discussions, and they are not able to provide any further value-add to the team, other than the basic book keeping. This, in turn, leads to...

  44. CHALLENGE 39: DELAY IN STARTING PROJECT (pp. 92-93)

    A client’s priorities change with the changing business demands, and they expect that your priorities are aligned accordingly. A project that has been kicked off and is in progress, can be shelved for a multitude of reasons. It ends up being a real test for the project manager, having to stop all activities that were planned meticulously and are currently under execution.

    The ensemble of acquired resources has to be released and there is no guarantee that you will get the same set of people when the project resumes. Sometimes there may even be a delay in resource ramp-up. Make...

  45. CHALLENGE 40: MISSING TEAMWORK (pp. 94-96)

    My team is working without any synergy between them, always fighting with each other, blaming and passing the buck, without actual focus on the problem. What do I do?

    You can read it all over a manager’s face when they have that ‘chaos’ look.

    It is always stressful to manage team disputes, in addition to the deadlines and deliverables pressures. There could be millions of reasons that are contributing towards the lack of team work. The IT world is a collection of varied colours, ages, sexes and cultural backgrounds. This combination in a team, can contribute to disputes. When there...

  46. CHALLENGE 41: PERFORMANCE APPRAISAL CONFLICTS (pp. 97-98)

    At the end of the project, it is important for the project manager to provide performance feedback to team members. This feedback should be recorded, and applied in their year-end HR appraisal, promotion cycles, and salary hike/bonuses.

    Feedback has historically been one of the most commonly misused management tools, especially when it comes to performance appraisals. Many people tend to associate the feedback element of the performance appraisal with reprimand for negative elements of one’s work or performance, without recognition of positive contributions and achievements, further fuelling resistance to the process. However, when initiated and delivered appropriately, feedback can be...

  47. CHALLENGE 42: PROJECT SYNERGY MISSING (pp. 99-101)

    The ‘blame game’ is the common challenge for a project manager, when a project involves multiple vendors and each of them is interrelated. In the planning stages, you would have identified multiple deliveries and their interdependencies, and appropriately contracted with multiple vendors to deliver according to their specialised skill sets. Usually things will be cordial during the initial phases of the project, but they may become uncomfortable as the testing phase begins.

    When a test defect is identified and assigned to a vendor, the problem starts if the vendor thinks that the root cause of the problem is originated by...

  48. CHALLENGE 43: STAKEHOLDER’S MICROMANAGEMENT (pp. 102-103)

    Sometimes there are conflicts in your organisation where your senior manager, or your client, can tend to micromanage your project, instead of delegating a set of expectations to you. They tend to work directly with your team, and hijack your project meetings, driving the project as if it was theirs, and giving conflicting messages and/or instructions to the team. It causes a lot of confusion to you, your team and project suppliers, on who is in the driving seat. In addition to confusion, it causes a lot of stress to the project manager, and it de-moralises the whole team. If...

  49. CHALLENGE 44: PROJECT STATUS REPORT ISSUES (pp. 104-105)

    A common complaint we hear from different project managers in Internet forums is there is too much reporting required in a week, and there is less time available to actually do the project management jobs. We have personally experienced this situation, where every day we had to meet one stakeholder outside the normal project status meeting and walk through the status reports with them.

    Typically, there is a weekly status report discussion forum where the client, business and senior IT managers will assemble, and this is where you walk through the report. You may be challenged in this forum.

    PMO...

  50. CHALLENGE 45: VENDOR CONTRACT CONFUSION (pp. 106-107)

    How can you decide the best way to engage your vendor for a development project? Is it on a time and material basis, or a fixed price basis? Before discussing the challenges in the models, we have provided a brief on the suggested models below.

    In this model, the vendor will invoice the project for the time spent by his people in the project. For example, if there are two people working on a project and they spend eight hours per day, with a daily rate of $500, then per week the vendor will invoice $5,000. There will be clear...

  51. CHALLENGE 46: WAR WITH PMO (pp. 108-109)

    Project managers always complain about their IT PMO team being project villains, because they annoy the project teams, they try to educate how reporting expectations must be met, they harass the teams to use ‘standards’, and they ask for additional reports the teams hadn’t planned to provide. In addition, most of the project managers don’t like them and no one wants to work with them. Why? Because they’re not seen as being there to help – they’re seen as being there to uncover mistakes and holler back to the management.

    Successful PMOs don’t start by dictating, and/or reporting, and/or controlling,...

  52. CHALLENGE 47: AMBIGUOUS STATEMENT OF WORK (pp. 110-111)

    Many projects rely on the supply of hardware, software, facilities and services by various vendors, or subcontractors. The project manager may need to:

    Select the best suppliers

    Negotiate terms and conditions

    Agree contracts

    Ensure the goods or services supplied are acceptable

    Deal with disputes

    Negotiate changes, where the client requires new or changed deliverables from the vendor

    Ensure the vendor, or subcontractor, is paid in accordance with the agreement

    Manage the relationship to maintain a good rapport.

    The project manager has an important part to play – but remember what you are not ….

    You are not the right person...

  53. CHALLENGE 48: AMBIGUOUS NON-FUNCTIONAL REQUIREMENTS (pp. 112-113)

    In this fast-paced world, users expect nano second responses to any interactions they are having with the systems. Be it on their smart phones, personal laptops or enterprise applications. For example, in today’s scenario a five second response time to a user’s query would be considered too slow.

    There are several factors that determine the performance of a system, some of which are network latency, load on the machines, shared resources/memory, and volume of the underlining data, For example, a user puts a query into the enterprise system to get all the details of the clients whose names start with...

  54. CHALLENGE 49: TOO MANY MEETINGS (pp. 114-115)

    Project managers spend 50% of their time in meetings with stakeholders, and often they will spend 90% of their time in meetings. As a project manager, you need to closely monitor how you are spending your time. Are you spending your time on unimportant issues/meetings? If yes, you need to avoid attending the meetings, or try to delegate.

    Some project managers have a strong urge to do everything themselves, as it gives them a feeling of control. To avoid this, build confidence in the person you are going to delegate the task to, and ascertain whether they are capable of...

  55. CHALLENGE 50: TROUBLED PROJECT RESCUE (pp. 116-117)

    Project failure can happen to anybody – and to any project. One of the interesting reports we read recently proved the point that just 30% of projects executed in the US are successful, and a huge 70% have failed to achieve all the stated project objectives. There are numerous reasons why a project results in failure. It could be that unexpected and unplanned requirement changes have caused your team to miss a series of deadlines. Maybe you lost a key member of your project team, or were given unrealistic deadlines. However, sometimes failure is in your control. You underestimated the...

  56. ITG RESOURCES (pp. 118-120)