IT Project Management

IT Project Management: 30 steps to success

PREMANAND DORAISWAMY
Copyright Date: 2011
Published by: IT Governance Publishing
Pages: 76
https://www.jstor.org/stable/j.ctt5hh791
  • Cite this Item
  • Book Info
    IT Project Management
    Book Description:

    This pocket guide is designed to help IT project managers to succeed, and is based on the author’s years of experience in IT project management. The guide’s step-by-step approach will enable those new to IT project management, or intending to make a career in this field, to master the essential skills.

    eISBN: 978-1-84928-101-0
    Subjects: Management & Organizational Behavior

Table of Contents

  1. Front Matter
    (pp. 1-4)
  2. PREFACE
    (pp. 5-5)
  3. ABOUT THE AUTHOR
    (pp. 6-6)
  4. ACKNOWLEDGEMENTS
    (pp. 6-6)
  5. Table of Contents
    (pp. 7-7)
  6. CHAPTER 1: CELEBRATE
    (pp. 8-11)

    As I welcome you to the world of IT project management, it’s time for you to celebrate. You have made the right choice by taking the initiative to pursue your career in the right direction. Your timing could not be more perfect: as the world slowly but surely comes out of recession, the IT industry is again gaining momentum. It is now impossible to find an industry that does not benefit from the power of IT. The IT industry has come a long way, and shows no signs of saturation.

    With changing consumer demands, businesses need to continuously innovate new...

  7. CHAPTER 2: KNOW YOUR ORGANISATION
    (pp. 12-14)

    Having become an IT project manager capable of bringing change to the business, you should now work to better understand your organisation. It is always better to have a view of the big picture and appreciate the change your project will bring to the business. By thinking like a customer, you will deliver a better project.

    For example, if you are doing an IT project for the stores division of a retail organisation, it is important for you to understand how a store works. You will need to understand what daily activities are involved at the store in order to...

  8. CHAPTER 3: KNOW YOUR PROJECT CAUSE
    (pp. 15-16)

    Now that you have been assigned to your project, it is important for you to understand why you are doing it. What is the project’s cause or business case? For example, the business case for making changes to banking computer systems might relate to changing financial regulations.

    For the IT project to be valid and active until it goes live, it should have a valid business case until the very end. In the above example, if the government was to decide not to bring changes to the financial regulations, then the very reason for making changes to banking computer systems...

  9. CHAPTER 4: KNOW YOUR PROJECT SCOPE
    (pp. 17-18)

    As the previous chapter examined your reasons for organising the project, we shall, in this chapter, discuss what you are going to deliver to achieve the business benefits.

    The project scope is the agreement between you and the business team about what are you going to deliver. This is the basic foundation upon which you are going to build your project. If you get this agreement wrong, then no matter how good you are, or how good your team is, the project will fail.

    The document containing the detailed information about your project is the requirements document. It is important...

  10. CHAPTER 5: KNOW YOUR PROJECT ORGANISATION
    (pp. 19-20)

    Compare your job as an IT project manager to that of a CEO, and your project to the organisation the CEO runs. If you consider any profit organisation, there will be investors who have, with confidence, put their money on your ability and your company product’s potential to sell. Investors will give suggestions and guidance on how you can achieve your goal via their representatives in your company’s board.

    Similarly, the business you work for will be investing money in your project, demonstrating confidence in you and the benefits the project promises. The business will also have their representative in...

  11. CHAPTER 6: FORM YOUR CORE TEAM
    (pp. 21-21)

    IT projects require team effort; you can’t handle one on your own. You will need a good team in place to deliver the project without any major issues. You should form a core team as soon as the project has been approved to kick-start. Generally, an IT project manager’s core team will have a very strong technical leader, a very good test leader and an energetic project support officer. For a large-scale project, the core team will expand to include IT architects, a volume test leader, a database administrator, etc.

    Sometimes, IT projects are outsourced to third party suppliers. In...

  12. CHAPTER 7: SET YOUR PROJECT GOVERNANCE
    (pp. 22-23)

    I do not encourage you to be bureaucratic, but at the same, I do not want you to run your project with no control whatsoever. For example, imagine a hospital where everyone – i.e. the nurses, administrative staff and support workers – plays the role of the doctor, each prescribing medicines. Think of the chaos in that hospital. A nurse should play the role of a nurse, not that of a doctor.

    Similarly, in your project, you should make sure that everyone doesn’t play the role of everybody. For example, business analysts should not approve the costs. The technical leader...

  13. CHAPTER 8: SPLIT YOUR DELIVERABLES INTO PARTS
    (pp. 24-26)

    To deliver a project successfully, you should know what you are going to deliver and what your project’s output will be. The output of an IT project is also called the IT project deliverable. Examples of IT project deliverables include an automated rail ticket booking system, a banking lending product computer system, or an iPhone™ application.

    It is very difficult to manage, control and plan an IT deliverable if it is too vague or too substantial. For this reason, it is good to break the IT project deliverable into manageable chunks.

    There are two approaches concerned: top-down and bottom-up approaches....

  14. CHAPTER 9: IDENTIFY THE TASKS
    (pp. 27-30)

    Now that you have identified your project deliverables and split them into manageable chunks, it is logical to progress to identifying the tasks involved in delivering them.

    You need to involve your core team in this activity, as you did in breaking down your deliverables. They should be able to help you to list the tasks involved in each of the sub-deliverables. You can use various brainstorming methods, such as Mind Mapping or the Delphi method, for this purpose.

    At this stage, it is very easy to get distracted by the effort, cost, resources, risks, and your capability to execute...

  15. CHAPTER 10: SEQUENCE THE TASKS
    (pp. 31-32)

    It will not be possible to carry out all the tasks identified in your project at same time, and so it should be sequenced in a logical manner. In order to identify the sequence of the tasks, it is important to understand the dependencies between them. For example, testing a program can be carried out only after the coding is complete. The coding of a program can be carried out only after the design of the program is complete.

    You will need to include your core team here again to help you. The dependencies between tasks can be identified as...

  16. CHAPTER 11: SET ROLES
    (pp. 33-34)

    Now you have identified the tasks, it is important for you to identify who will do what, i.e. which resource or person you will require to complete each task you have identified.

    It requires skill to assign tasks to people. You should assign the right task to the right resource. You should consider various factors, such as whether the resource has the knowledge, experience in similar tasks, and the capability of handling high complexity tasks.

    You need to make best use of the resources you have. Due to unavoidable situations, you may sometimes have to assign a task to a...

  17. CHAPTER 12: ESTIMATE THE TASKS
    (pp. 35-36)

    After you have identified the tasks and their owners, you will need to get an estimate for each of the tasks in order to arrive at the total effort required for the project.

    There are many estimation methods available to you, such as the function point method, the complexity method, and the Delphi method. You will need to choose the right method for your project.

    Estimations should be carried out for each task with the resource assigned to it. After having understood and gained a ballpark estimate for the effort required for each task, you can add a buffer figure...

  18. CHAPTER 13: CONSTRAINTS TO ACHIEVING THE TASKS
    (pp. 37-39)

    After you have figured out the tasks, their owners and the effort required, it is important for you to discuss it with the team to understand the constraints in achieving the tasks. There are various types of task constraints, such as date constraints and resource constraints.

    It is not the case that all tasks have constraints. By default, tasks will have no constraints; if this is the case, you can start work on a particular task as soon as the preceding task is complete.

    Sometimes, a particular task cannot be started until a particular date. Reasons for this could include...

  19. CHAPTER 14: CREATE A PROJECT PLAN
    (pp. 40-41)

    You can create a project plan with the information you have collected or learned up to this point, such as the project deliverables, tasks, dependencies, resources, the effort required and constraints.

    There are many established tools available on the market to facilitate you in making a project plan. Some commonly used tools are Microsoft®Project Plan®, Clarity®and PPM Studio®.

    In Project Plan®, you can view your plan in many report formats, such as Gantt chart format (giving a pictorial representation of your plan), resource view, or day-wise activities view. These formats will help you to understand how your plan...

  20. CHAPTER 15: ESTIMATE COSTS
    (pp. 42-43)

    The project cost represents the total amount of money your project will incur in delivering the completed product. Senior management will make a decision on whether to go ahead with the project or not, based on the estimated cost, business benefits, net present value, payback period and other costs.

    To arrive at the project cost, you need to take various factors, such as resource costs, infrastructure costs, maintenance costs, support costs, build and test costs, training costs, etc. into consideration.

    Resource costs are usually calculated on a per-hour basis. By multiplying the total effort allocated to the resource with the...

  21. CHAPTER 16: BASELINE AND GET APPROVAL FOR THE PLAN
    (pp. 44-45)

    Once you know the high level or milestone plan and the project cost, you will need to inform the key decision makers or stakeholders about your project to gain approval for it.

    For you, the advantage of doing this will be that the management will then back you up to deliver the project with the agreed timelines and cost.

    Once you have gained approval from senior IT management, you will need to baseline the plan. In baselining the plan, you commit to the dates and cost of the project; any deviations from these will then not be acceptable without further...

  22. CHAPTER 17: INITIATE THE PROJECT
    (pp. 46-47)

    Once you have gained approval for the baseline plan and the project budget cost, it is time for you to kick-start the project.

    As a first step, you should create a project brief document that outlines the project objective, project business case, project scope, project benefits, project high level plan and its cost details. You can use this project brief document to share, with the team or other stakeholders, the details about the project and talk about what you need to achieve. This will provide a good introduction to the project.

    You can organise a project kick-start meeting to talk...

  23. CHAPTER 18: TRACK YOUR TEAM
    (pp. 48-49)

    After you have initiated your project, you will execute your project by assigning the project activities to your team, as outlined in your project plan.

    You will need to track your team in terms of line management – i.e. make sure they are doing their activities without any issues, and without wasting their precious time on any unimportant tasks. You will need to check whether they have all they need to progress with their tasks by facilitating meetings with the appropriate people, and by making sure they fill in their timesheets properly.

    You will come across two types of team...

  24. CHAPTER 19: TRACK YOUR PLAN
    (pp. 50-51)

    As you progress with the project execution, you will need to take some stock of how much you have completed and how much still needs to be completed. You can then give status updates to your senior IT management, and take corrective action if you find your project is off track.

    There are several different mechanisms available to track your plan – you should choose which one best suits you. Daily project stand-up meetings can be useful – in these meetings, your project work stream leaders can share what they had done the day before, what they are planning to...

  25. CHAPTER 20: TRACK YOUR ISSUES AND RISKS
    (pp. 52-54)

    During your project life cycle there will be many uncertainties and problems you might have to face and manage.

    Project risks are the events that might occur and would impact your project scope, plan, quality, resources and costs. You will need to have discussions about these risks with your team at every stand-up meeting or project weekly status meeting during your project, and update the ongoing risks if there are any changes. If the risk no longer exists, you should close it.

    You will need to track all the risks in your project risk register, which will contain such details...

  26. CHAPTER 21: REPORT YOUR PROGRESS
    (pp. 55-56)

    You will need to communicate the progress of the project to the key stakeholders in your project, so that they are not kept in the dark and can make informed decisions or act on any action items.

    Your communication plan for the project should make up-front statements about what you are going to communicate about, with whom and when. It will make sure there are no surprises for the people at the end of the project.

    You should deliver project weekly status reports to your IT PMO or senior IT management. They should be presented in a pre-agreed template. You...

  27. CHAPTER 22: UNEXPECTED CHANGES
    (pp. 57-58)

    It would be a dream come true for any project manager to deliver a project without making changes.

    Changes can happen to anything during the project life cycle. They can occur in the requirements, design, software code, test cases, test scenarios, infrastructure, go-live dates, team organisation, IT board, government regulations, world events, etc. You cannot plan for them all.

    At the same time, however, you can anticipate some changes in advance and prepare yourselves for them.

    For example, if one of your resources becomes pregnant during the project, you can anticipate some unplanned absence or planned maternity leave. You can,...

  28. CHAPTER 23: PLAN YOUR GO-LIVE
    (pp. 59-60)

    As the project end date approaches, you will need to start thinking out the project go-live approach and plan how to implement the system smoothly. Depending on the type of project, its complexity and the nature of the business, you will need to consider a pilot approach, phased approach, parallel run approach or a cut over approach.

    You will need to get your team to write down the detailed project implementation plan. This should list the tasks to be carried out during the go-live. These tasks should be planned down to the minute – the more detailed your implementation plan,...

  29. CHAPTER 24: ENGAGE WITH THE DEPLOYMENT TEAM
    (pp. 61-62)

    Due to their busy schedule, the IT operations team will need to be the first to preview your project go-live approach and project implementation plan. They will need to plan out their time for your go-live activity.

    In most cases, the deployment team will consist of a deployment manager (a role typically assumed by the project manager), database administrators, server administrators, storage and capacity team members, network administrators, desktop support engineers, business analysts, your development team-leaders and a release manager (this role also typically assumed by the project manager).

    Depending on the complexity of the project, the deployment team will...

  30. CHAPTER 25: PLAN THE SUPPORT
    (pp. 63-64)

    Before implementing your project, you should be sure that the support plan is in place and that you have gained approval from your senior IT management, business team, IT operational team, and application support team.

    Immediately after gaining project support, the project 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.

    The IT application support...

  31. CHAPTER 26: PLAN THE TRANSITION
    (pp. 65-66)

    Project transition is the phase during which project ownership will be transferred from your project’s warranty support team (i.e. your project development team) to the IT application support team.

    It is very important that you plan for the transition well in advance, so it takes place very smoothly and without glitches.

    Once your project has transferred to IT application support, they will be responsible for fixing any issues, resolving any business user queries, and taking care of other activities, such as backing-up the database, network support, hardware support, etc.

    It will be your responsibility to create a transition plan that...

  32. CHAPTER 27: GO-LIVE
    (pp. 67-68)

    Project go-live makes your project operational in the real environment, as the business starts to use the system. The business benefits of the project will begin to be realised at this stage.

    You should have various plans, such as an implementation plan, support plan, transition plan and knowledge transfer plan, approved by different key teams – such as the business team, IT deployment team, development team, IT application support team, IT operations team, etc.

    Your project’s testing phase should have been completed, and it should have met the quality criteria agreed. The business users should also have completed and signed-off...

  33. CHAPTER 28: CLOSE THE PROJECT
    (pp. 69-69)

    You may need to formally close the project if, for example, the project goes live and is transitioned to IT application support, or if senior management decides to cancel the project – this for such reasons as an invalid business case, the cost overshooting benefits, technical complexities, etc.

    You will need to carry out important activities at the time of project closure, such as sharing your findings with the IT PMO group, archiving the project documents and storing them in the common repository, archiving important e-mails, formally closing the project code, authorising payments of any unpaid bills or invoices, disbanding...

  34. CHAPTER 29: SHARE THE LEARNING
    (pp. 70-71)

    One of the main objectives for any organisation is to learn from their previous experiences and leverage that learning in forthcoming initiatives, actions and projects.

    During your project life cycle – from initiation to the go-live phase – there may be numerous occasions where things do not go according to plan. There may be many achievements, new best practices and out-of-the-box solutions to the issues, etc. that you could share with your IT organisation’s PMO group. They could then record them in their repository, and use them for other projects and groups.

    The project learning will be shared with IT...

  35. CHAPTER 30: CELEBRATE
    (pp. 72-73)

    I would like to congratulate you on completing your project successfully; it is now time for you to celebrate again. Celebrate with your team and reflect on the good things, funny moments and achievements. It will be a motivating experience, providing your team with encouragement for your next project.

    You can use this opportunity to talk to your group about the areas of improvement and how things could have been planned or carried out by you and your team. This will add real value to the discussion and give the team an opportunity to increase their work efficiency.

    I take...

  36. ITG RESOURCES
    (pp. 74-76)