You are currently on IBM Systems Media’s archival website. Click here to view our new website.

Bookmark and Share

Recent Posts

IT Project Management Business, Methods and Technical Matters

September 10, 2018

Last week, I started a new series on project management and began to revisit some research that I had done previously on project management. By “some research” and “done previously,” I mean that I previously reviewed and categorized data from many articles and other studies and used it to create a model of the factors that contribute to project failure. Last week, I discussed two factors: management of the project and the people on the team. This week, I’ll finish the model discussion by covering the business, method and technical dimensions of the study. This will set the stage for next week’s discussion of IT project management trends. 
IT projects consume resources, so typically, there are business aspects of the project that focus on alignment, funding, risk and ROI. Without attention to these areas, you risk shortcoming such as not managing changing objectives and goals; lack of proactive risk management; poor coordination between technology and finance; and insufficient performance measurement.
For this reason, project managers must work on tasks such as implementing a straightforward change-management process, establishing a risk-management assessment tool, including finance representation on the team, formalizing a business case and identifying discrete performance measurements. Not all of the mentioned steps and processes may be required, but it’s prudent to include the most important ones. Why wouldn’t you spend the time to run a risk-management tool if it means gaining a deeper insight into the project? 
The three checklist items below, relating to the business dimension, came from my experience and research.  
  1. Working closely with finance to understand financial success criteria and measures? If no, is it possible to request support from the finance organization?
  2. Risk-assessment steps part of the project plan? If no, is there an internal risk-assessment tool that can be used? If not, what about an external tool like Risk Check or Risk Watch?
  3. Aligned with company and constituent goals? If no, what can be done to ensure alignment?
“Method” pertains to how the project is carried out—the approach, procedures and tools used. The method used might be a simple organic one including items that appear in internal company guidance. The suggested method might include steps like the ones below:
  1. Set up an electronic project notebook (repository)
  2. Establish written project objectives (communication)
  3. Work with the technical lead to establish tasks within phases (planning)
  4. Ask team members to estimate tasks (estimating)
  5. Create a formal project plan and manage to it (directing and using tools)
  6. Proactively solve problems that arise (problem solving)
These steps cover all the basics for any IT project. However, a company with an internal project management center of excellence will certainly provide more detailed guidance and requirements depending on the resources to be expended and the project risk. As with the other dimensions, here are checklist items relating to the method used to manage the project. 
  1. Utilizing a proven methodology? If no, is there an internal company method that you can discover and use?
  2. Utilizing tools and automation? If no, are there internal company tools that you can discover and use?
Every IT project has a technology dimension. It might involve hardware, software, testing and the relationships or integration between these elements. Over time, the technical dimension has become more challenging. Why do I write this? IT projects are more challenging because there are many more elements that might need to interact. Consider just programming languages. Where there was once COBOL and BAL, there are Java, Python and dozens more. This story is the same for middleware and many other types of software that appear in popular software taxonomies like the one from IDC. Volume and complexity are just two areas of technical challenge.
These three checklist items below relate to the technical dimension of the project. 
  1. Hardware vendor integration part of the project plan? If no, is there is no need for it? Is this an oversight?
  2. Software dependencies and relationships understood? If no, what activity can you carry out to better understand the relationships?
  3. Points of integration understood? If no, is there an integration checklist you can utilize?
Recap of the Importance of the 5 Factors
Now that I have discussed the five elements of the model, this pie chart indicates the relative importance of each factor. If I were to do the research all over today, I might find that the technical aspects of the project contribute to failure more frequently than in 2011. This may or may not be true, but it just feels that way right now.   


Next week, I will explore current IT PM trends as found and discussed in the popular literature.  

Posted September 10, 2018| Permalink