ITEC-3040 IT Project Management
Project Management: Understanding Organizational Requirements | |
File Size: | 5044 kb |
File Type: | pptx |
Note: This slideshow contains a voice over, highly recommended to download and listen as SlideShare does not support this feature fully.
Project Sweeping Changes
An organization moving to IT-enabled processes will see massive sweeping changes in how its operations are managed. This means that any projects which are specifically aligned with the strategic goals of the organization, and moving the organization towards the project outcome of IT concurrency, should receive the highest priority. However, all projects should first be checked for Net Present Value (NPV) and weighted based on strategic organizational guidelines. Where a project does not meet agreed NPV targets, or weighted values are not aligned with strategic goals, projects can be set aside for review at a later date. In the instance that there are more projects than the organization can support at one time, staff will need to be deployed based on the criticality, time sensitivity, and strategic relevance of each project. Since these projects are changing the entire organization, all areas will believe their projects are the most important. The key here is to ensure those projects which will affect the organization the greatest have the highest support both horizontally and vertically across the organization. Once again the project managers will need to return to the NPV and Weighted values of each project to ensure that projects are receiving the correct level of support from the organization. Reference Schwalbe, K. (2014). Information Technology Project Management (7th ed.). Boston: Cengage Learning. |
Project Management Tools
The primary reason behind project management tools are not the automation, but the organizational capacity they bring to a project. Rather than relying on massive amounts of spreadsheets and snail mail, project management tools, such as Jira or SharePoint, offer a way to centralize and organize work groups. That is, this is what they should be used for and how a good project manager would use them. Project management tools should not be used to automate project flow or project check points. A good project management tool allows a PM to input project WBS and assign resources to each task, tracking work schedule and solution input. In fact, the tool can even report on overall bug I/O throughput, as well as, patch scheduling and completion status. These are all data points which enable a PM to make decisions about the projects overall health. This data can then be aggregated and analysed by the PM, to report to stakeholders. Project management tools which take away the ability of a PM to analyse project health, and instead automate project flow, can lead to project disaster when different parts of a project team do not align in workflow or throughput. For instance, project A has a development team lagging behind in bug resolution, but the project management tool states that the next phase of testing will begin regardless. A PM could see this problem, renegotiate the timescale with stakeholders and keep the project on track. On the other hand, the tool would report up the chain the project was on track, even though reality said otherwise. A project manager should use tools that enable their ability to make decisions about the project. Tools that take this decision making ability away should be avoided at all costs. That is, as long as the tool being used does not alter the decisions a PM would make, only enable their ability to make the decisions faster or with more information, then there is no reason to not use project management tools. Reference Schwalbe, K. (2014). Information Technology Project Management (7th ed.). Boston: Cengage Learning. |
Information Technology Upgrade Project Work Breakdown Structure | |
File Size: | 42 kb |
File Type: | docx |
This is an example Work Breakdown Structure for a hypothetical organization requiring their entire hardware, software, and infrastructure fleet to be upgraded due to web application changes which need the additional support such an upgrade will offer.
Bachelor Degree Timeline: Gantt Chart
Now that this program of study is nearing its completion, having this information from the start would have allowed for a much greater level of planning and anticipation. That being said, the critical path is fairly strait forward, and as such, has allowed for the flow of this life project to occur with minimal interruptions. That is, if the critical path were to be laid out in full from left to right, it would be a single straight line. From the first course in “Developing Student Portfolios” to the last course “ITEC Capstone.”
The primary reason for this straight line is in how the progression of study has run its course. In each quarter, only two classes were taken, each class was taken at half quarter intervals, meaning that before the next class could start the previous class must have finished. However, there are some milestones, points at which key classes must have been finished before future classes are even available. The milestones act as both checkpoints and alerts to whether the program of study is moving at the expected pace.
In those instances where a class was not available during the time frame required, the entire progression of study must be pushed back by six weeks. Fortunately, the time frames of all courses has led to only two instances of this occurring, both marked in red as “Not Available.” Each of these pushed out the time line by six weeks. The last instance is slightly more painful, as had the expected course been available, one extra week could have been saved due to mandatory one week breaks between quarters.
Now that this program of study is nearing its completion, having this information from the start would have allowed for a much greater level of planning and anticipation. That being said, the critical path is fairly strait forward, and as such, has allowed for the flow of this life project to occur with minimal interruptions. That is, if the critical path were to be laid out in full from left to right, it would be a single straight line. From the first course in “Developing Student Portfolios” to the last course “ITEC Capstone.”
The primary reason for this straight line is in how the progression of study has run its course. In each quarter, only two classes were taken, each class was taken at half quarter intervals, meaning that before the next class could start the previous class must have finished. However, there are some milestones, points at which key classes must have been finished before future classes are even available. The milestones act as both checkpoints and alerts to whether the program of study is moving at the expected pace.
In those instances where a class was not available during the time frame required, the entire progression of study must be pushed back by six weeks. Fortunately, the time frames of all courses has led to only two instances of this occurring, both marked in red as “Not Available.” Each of these pushed out the time line by six weeks. The last instance is slightly more painful, as had the expected course been available, one extra week could have been saved due to mandatory one week breaks between quarters.
Gantt Chart
The blue line marks the current time period.
Reference
Schwalbe, K. (2014). Information Technology Project Management (7th ed.). Boston: Cengage Learning.
Walden University. (2012). Home. Retrieved November 3, 2012, from Walden University: http://www.waldenu.edu
The blue line marks the current time period.
Reference
Schwalbe, K. (2014). Information Technology Project Management (7th ed.). Boston: Cengage Learning.
Walden University. (2012). Home. Retrieved November 3, 2012, from Walden University: http://www.waldenu.edu
Project Management Software Comparison | |
File Size: | 128 kb |
File Type: | docx |
A comparison of four project management applications: Microsoft Project, OpenProj, RedBooth, and Jira.
PPI Project Resource Sourcing: In-House, Outsource, or Hybrid | |
File Size: | 105 kb |
File Type: | docx |
Extract: Plush Packet Incorporated (PPI) is intent on updating their aging website to meet the demands of a global audience. However, the method in which PPI should go about this upgrade is still a question. There are three primary alternatives that management must consider: an in-house build by PPI development staff, outsourcing the entire project to a consulting agency, or a combination of these two factors. The end result should be a product that PPI will be able to use and expand upon for years to come.
Planning for the Worst
Project Risk management should obviously fall firmly in the center of pessimism and optimism. That being said, how a Project Manager balances the project on this fine line revolves around the overall project scope. The primary questions about the project the PM needs to answer are: Is the organization in a position to financially ensure the success of the project, is the organization’s position in the market amenable to the success of the project, and are there any political or socioeconomic issues which may delay or halt the success of the project? Each of these leads down both a pessimistic and optimistic path of risk assessment.
The pessimist looks at each of these in terms of what is the worst case scenario. Financially the project could bankrupt the organization, the market could have a new contender making our project redundant, new laws or social norms force our project to be delayed due to having to adapt to meet requirements. The optimist, on the other hand, looks at how each of these could be taken to advantage. By taking a financial risk the project could have a higher ROI, the market is primed for the project’s output and contenders will be hard pressed, political or socioeconomic issues can be worked around and may even be to the advantage of the project.
Enough planning for optimistic and pessimistic approaches comes when all stakeholders are satisfied with the level of risk mitigation. That being said, it is in the best interest of the PM to ensure that risk mitigation has been addressed to the fullest extent possible. For instance, if stakeholders are satisfied with the minimum amount of mitigation planning, the PM should take a stand and move risk mitigation a few steps further to ensure project success. After all, if the project fails due to a lack of sufficient risk planning, it will be the PM who is blamed.
Reference
Schwalbe, K. (2014). Information Technology Project Management (7th ed.). Boston: Cengage Learning.
Project Risk management should obviously fall firmly in the center of pessimism and optimism. That being said, how a Project Manager balances the project on this fine line revolves around the overall project scope. The primary questions about the project the PM needs to answer are: Is the organization in a position to financially ensure the success of the project, is the organization’s position in the market amenable to the success of the project, and are there any political or socioeconomic issues which may delay or halt the success of the project? Each of these leads down both a pessimistic and optimistic path of risk assessment.
The pessimist looks at each of these in terms of what is the worst case scenario. Financially the project could bankrupt the organization, the market could have a new contender making our project redundant, new laws or social norms force our project to be delayed due to having to adapt to meet requirements. The optimist, on the other hand, looks at how each of these could be taken to advantage. By taking a financial risk the project could have a higher ROI, the market is primed for the project’s output and contenders will be hard pressed, political or socioeconomic issues can be worked around and may even be to the advantage of the project.
Enough planning for optimistic and pessimistic approaches comes when all stakeholders are satisfied with the level of risk mitigation. That being said, it is in the best interest of the PM to ensure that risk mitigation has been addressed to the fullest extent possible. For instance, if stakeholders are satisfied with the minimum amount of mitigation planning, the PM should take a stand and move risk mitigation a few steps further to ensure project success. After all, if the project fails due to a lack of sufficient risk planning, it will be the PM who is blamed.
Reference
Schwalbe, K. (2014). Information Technology Project Management (7th ed.). Boston: Cengage Learning.
Comment Box is loading comments...