Dr. Atul Gawande author of “The Checklist Manifesto: How to Get Things Right” explains, in detail, the benefits of the checklist. He points out some hints about the checklists. For example if the list is too long the people will not use it. Checklists are not only for simple things, as he points out, but also for complex things, especially when the unexpected occurs. In unexpected situations our stress level increases blurring our thinking. Checklists and training can rescue us from such situations. A situation like this was the US Airways 1549, where 90 seconds after takeoff and while was climbing it crossed the path of the geese. They lost power of both the engines. The main pilot, Sullenberg, took over the plane from his copilot and his copilot immediately pulled out the engine failure checklists to see if he could put them back online. With the help of luck and the professionalism of the pilots, the airplane was saved.
I have great personal experience creating and using checklists. I am using checklists daily both at work and home. I am using a checklist when I create a new project, when I gather project requirements, when I do risk management, when I check test plans, when I deploy software to production servers. I am keeping a version number of my checklists and make sure that I have and use only the latest version. I have realized additional benefits using checklists. They are great to capture experience. I am updating the list to include checks or tasks that prevent delays and / or failures. This is a great time saver which is another great characteristic of the checklists. Having great checklists helps you also to delegate some tasks more efficiently. You do not have to explain everything if they have the required training they can just follow the steps to get the right result.
I am looking forward to hear your experience with checklists.
]]>The answer is yes but you need to identify and manage the project’s risks. Remember that risks can be positive or negative.
This is an informal introduction to risks for software projects coming directly from my experience in project management. I am managing software projects for many years and I have found some common problems in almost all software projects that if you do not handle properly can lead your project to disaster. I have used different software development methodologies from Waterfall to Scrum. In addition, I am preparing a series of articles dedicated to risk management that will be available in the near future from this blog.
Let’s start!
Managing or coaching a project team is a very exciting experience. The good think is that it is in your hand to make this experience a positive one for all involved in the project. Think positive and be proactive.
Scope
You have to have a vision statement for the project and commitment for the top management for your project. If you do not have that do not even think on starting your project.
An example of scope is “Go to the Moon” as set by President John F. Kennedy‘s on May 25, 1961
Make sure that you have a list of deliverables that are in scope and also that you have an out of scope list.
Requirements
You have to have business requirements for your project. This is a tricky one because you need to define how you will accept the business requirements. Things to be watching for when you deal with business requirements:
Team
Select the best that you can afford or are available. Do team building activities. Remember the Tuckman‘s stages of group development: Forming – Storming – Norming – Performing – Adjourning.
You goal is to create a cohesive team that can perform effectively and efficiently. There will be some frictions but is up to you to coach the team successfully out of a crisis.
The team have to know the technology they are going to use to build the software. The better your team, the better the possibilities of success for your project.
Software Architecture
Do the software architecture phase. If you use Scrum you can do this before you start your sprints or you can have your first sprint dedicated to software architecture.
Allowing time for architecture will save your team (and yourself) a lot of wasted time. Software architecture is a huge subject to be analyzed here. Involve a software architect. Software architects can depict the system is such a way that the system’s behavior will be visible to the business and the implementation teams. The architecture is the primary carrier of system qualities such as performance, modifiability, and security under a unifying architectural vision. Developers see the details of the solution but many times fail to see the system as a whole.
Risk Management
Plan to have frequent (weekly) risk management meetings. You need to identify, assess and prioritize the risks of you project. Leaving your risks unmanaged is a way to ensure your project’s failure.
Estimation
There is always the risk that you did not estimate correctly the effort. Always use more than one estimation method and triangulate. This is a difficult task but if you have performed the previous phases then you and your team have a very good understanding of the challenges of the project and you will be able to create a realistic estimation. You estimation should include all time needed to finish the project this means also time for meetings etc. Remember that various deployments take time and also that there will be bugs in the software. Again, this is a very big topic and it will be covered separately.
In addition according to Cerpa Narciso and Verner M.June. (2009), the 3 factors that contributed most for an in-house project failure are that the delivery date impacted the development process, project was underestimated, delivery date decision was made without appropriate requirements information.
Quality Assurance
Involve your quality team as early as possible. Make sure that they can create test cases out of the business requirements. Use a team of testers.
Quality Assurance will help you with validation and verification of your project. Validation ensures that “you built the right thing”. Verification ensures that “you built it right”.
Audit your development team that they are using the defined quality processes.
If you do not have a quality system in place you are in trouble. Standardizing processes of software projects enforces a unified way of project delivery in the organization.
The most commonly used quality frameworks are the ISO 12207, the Capability Maturity Model Integration (CMMI) and the project management body of knowledge (PMBoK). (Fairley, 2009, p.10)
Executing the project
The way you execute your project is key for the project success. There are different ways to execute your project; this depends on the methodology you are using. Here also experience helps. There are several keys to help you succeed.
There are many things to say for project execution. The above list is by no means complete. Project execution is a big subject that I will treat separately with articles in this blog.
Communication
Have everyone informed. Create a communication plan. Be proactive and not reactive. Create status reports and manage the expectations of the involved parties. Failure managing the expectations introduces unnecessary risks to your project. Communication can take up to 70% of your time.
Environment
Your project is not in isolation. It interacts with the surrounding environment. Changes in the environment affects your project. For example inability off subcontractors to deliver their work might affect your project’s success.
Epilogue
Is the above list complete? No, it is not complete. It is a starting point to help you see some major areas that can hurt your project. With this article we only are scratching the tip of the iceberg. Managing software projects is really exciting and requires full commitment of your time and effort. Good luck!
References
Cerpa Narciso and Verner M.June. (2009). Why did your project fail?. Commun. ACM 52, 12 (December 2009), 130-134. Available from: http://doi.acm.org/10.1145/1610252.1610286
Fairley, E. R. (2009) Managing and leading software projects. IEEE Computer Society. John Wiley & Sons., Inc., Hoboken, New Jersey
Project Management Institute(2008A) A guide to the project management body of knowledge . 4th edition. Newton Square, Pennsylvania: Project Management Institute Inc
Project Management Institute (2008B). Practice standard for project risk management Newton Square, Pennsylvania: Project Management Institute Inc.
For a project to be successful risk management should be done early in the project planning. The plan risk management should identify the risks, perform qualitative risk analysis, perform quantitative risk analysis and plan risk responses. Defining a Risk Breakdown Structure helps to identify project risks. Typical categories where risk might occur in a project are technical, external, organizational and project management.
Shenhar (3) discusses the technological uncertainty for four types of projects: Low-Tech (ex. road building), Medium-Tech (ex. Existing product improvement), High-Tech (ex. New systems) and Super High Tech (ex. the Hubble telescope). Ways to reduce uncertainty involved design cycles and design freeze.
There are mainly three categories of risks relating to software projects:
Project Risks which affect the availability of resources or the time constrains of the project. From experience I know that usually developers are very optimistic when setting deadlines. They do not anticipate difficulties that may occur in the development phase of the project. This easily creates a problem with time and completion of the project. It has also implications with the total cost of the project.
Product Risks which affect the performance, scalability or the quality of the software under development. Again, from experience I know that is totally different a design that supports a few hundred users to one that supports simultaneously thousands of users. Creating multithreaded code and introducing locks into the system to avoid race situations involving shared resources increases the complexity of the code and complicates the testing of software components. I have more than 20 years of programming experience and I have seen good and bad quality code. I have also seen code that was fully commented, not well documented having no bugs but it was unnecessary complicated. This type of code can be spotted only from experience and the cause of it is job protection. Programmers thought that by writing code the way they did they were protecting their jobs because no one else would be able to deeply understand the code. In my opinion quality of the code cannot be counted by bugs and bug fixes as many organizations practice but with internal and external (if possible by an independent consulting firm) code reviews.
Business Risks which affect the business itself. For example a change in technology that a system assumed.
To have a plan ready to respond to risks that might occur, can save the project depending on the severity of the risk. The risks that are worst are the ones that are unknown and have an unknown outcome. There are several strategies available to reduce or control the risks:
As a conclusion the most certain thing about projects is that risk factors will occur in one form or the other. Reducing or controlling the risk is a task that is performed by a team.
From experience I know that is also important to take under consideration the external environment when devising risk plans. This post is an introduction to possible risks associated with software development projects. I will continue with more in depth postings on the subject.
References