a reflexion on PROJECT MANAGEMENT SOFIE LINDBLOM TNM090 SOFTWARE DEVELOPMENT LINKÖPING UNIVERSITY

Transcription

1 a reflexion on PROJECT MANAGEMENT by SOFIE LINDBLOM TNM090 SOFTWARE DEVELOPMENT LINKÖPING UNIVERSITY

2 Project management is like juggling three balls time, cost and quality. The Project team is like a troupe of circus performers standing in a circle, each juggling-three balls and swapping balls from time to time. G. Reiss INTRODUCTION What is project management? After spending some time reading about the subject I began to realize that this is one of those fields where you can not read yourself smart. Experience needs to be gained by actually participating in real projects, adapting the concepts of models, processes and methods. Linköping University is very good at enrolling students in projects of various kind. Unfortunately most of the projects are protected from the real world, in other words: they never leave the classroom. This limitation leads to that many important aspects of project management get bypassed. Cost planning, risk management but mostly a life after the final deadline for your product are things I strongly miss in university related projects. In this reflexion I will compound my own experiences of project management with the perspectives given in Software Engineering by Shari Lawrence Pfleeger and Joanne M. Atlee A goal is a dream with a deadline Napoleon Hill DELIVERABLES From previous projects I have derived that this section is one of the hardest to anticipate. In order to estimate what can be delivered, within what time frame and to what cost requires both expertise in the field and previous experience. Pfleeger and Atlee suggests to sit down with customer and list all project deliverables early in the development process. When will, for example demonstration of documents, subsystems, accuracy and performance take place? If the project team understand the customer s needs and expectations from the very beginning misunderstandings and delays can be avoided. I completely agree with the authors and are of the believe that an honest communication with the customer is the key to a successful collaboration. For some projects it might be a good idea to make this initial process iterative. When the team have had the time to digest the deliverables and make a preliminary project plan the agreed deliverables might need to be adjusted. We will either find a way, or make one. Hannibal MILESTONES AND ACTIVITIES With a list of expected deliverables it is easier for the project team to get a fair overview of what needs to be done in order to deliver the required product. Depending of the size of the project the team might have to apply some kind of breakdown structure. Top-down or Bottom-up are two common methods. Applying one of these methods enables the developer to divide the project into parts which can be solved autonomously and then put together again to a finalized product. Depending on which model the team is working with these parts are named differently. Sprint, Step or Phase to mention a few. The underlying logic is some what similar though. The different parts of the project can be described as

3 activities. When an activity is completed we reach a milestone. It is common to display current status of the project prototype to the customer at each milestone. When the team has reached a milestone they usually move on to the next activity. Activities can also run concurrently depending on the development method the team has chosen. Milestones, deliverables and activities combined with a time schedule, allocation of manpower and cost estimation makes the fundamental pieces of a project plan. Depending on the situation additional information might need to be considered. For example specific software/hardware, a testing phase, security and risk management. In order to track progression and make sure the development sticks to the project plan an activity graph or activity tracker can be used. Pfleeger and Atlee mentions a few in the chapter Tracking Progress. I find them quite hard to interpret. There are many online tools available which are very clever when it comes to organize activities on a timeline and then track the progress. I tried a few different ones but keeps coming back to one called SeeNowDo. It has a feature which allows you to give sub team's activities different colors. Some people call it the wet dream of a control freak I could not agree more. No one can whistle a symphony. It takes a whole orchestra. H.E. Luccock PROJECT ORGANIZATION When the project is sliced up into pieces and converted to activities it is often clear which roles that needs to be assigned in order to carry out the tasks. In a software development project common roles are requirement analyst, system designer, program designer, interface designer, tester, security and risk analysts. Depending on the implementation the needs vary. From my experience there is beneficial to assign roles after creating the project plan. This approach assures that no one in the team ends up empty handed. When roles are determined and everyone is (hopefully) satisfied and excited to get started it is efficient to decide how to communicate in the group. Again there are many different approaches and which one to choose depends on team size, working model and type of project. In some cases there are more complex differences like background of the team members, prefered work style and cultural differences. During my exchange year at National University of Singapore I on purpose tried to place myself in multicultural teams. I worked with people from India, China, Vietnam, Canada, Denmark, and Singapore.This was an amazing experience and insight. It turned out that even if we were approximately the same age and studied the same subjects we often had completely different approach on how things were done and how to collaborate in a group. At times it was extremely demanding and I regretfully missed my Swedish classmates. But in the end it was truly rewarding and interesting. In my current software development team we have chosen an organization which combines egoless programming and chief programming. Discussions are held openly in one of the forums we created. While more specific questions regarding certain areas are directed to me in the role of project leader. In order to become more effective the plan is to gradually shift over to the scrum of scrums -method when we have come further into the developing process.

4 Good judgment comes from experience, and experience comes from bad judgment. - Fred Brooks EFFORT AND COST ESTIMATION Inaccurate estimations are unfortunately both common and dangerous. No matter how many expert judgements or methods applied to estimate cost and effort, things can and most probably will go wrong at some point. Our lecturer Karl Johan Palmerius mentioned in one of the labs earlier in the course that There is only one constant in software development: there will be change. One month into our first big development project I already feel that this is very true. We bumped into so many unplanned obstacles that it was actually hard to keep the team motivated. My approach to this was to go back to the project plan and get an overview of the errors. List possible solutions to these errors and present the list to the group. Together we picked one solution and directed all our efforts towards that specific solution. We are now moving forward again. Pfleeger and Atlee list the most common causes of inaccurate estimates, it was a very good read before making a decision on how to handle our team s errors. Many project teams have had problems with this type of estimations, there are therefore several models on how to minimize errors related to cost and effort. More in-depth explanations of a few of these methods (expert judgement, algorithmic and machine-learning) are found in section Effort Estimation in Pfleeger and Atlee s Software Engineering. Assumption is the mother of all screw ups H.E. Luccock RISK MANAGEMENT, SECURITY ANALYSIS AND TESTING How is a risk defined? Pfleeger and Atlee distinguish a risk from other project events by looking at three things: 1. A loss associated with the event (risk impact) 2. The likelihood that the event will occur (risk probability) 3. The degree to which we can change the outcome (risk control) I interpret this three things as a sequence. First we determine what might be lost (time, money,accuracy, understanding, etc). Then we need to detect the certainty of the risk to occur, this is done by measuring on a scale from 0 to 1. Finally we analyze possible solutions to avoid the risk transforming into a real problem. To prevent ending up in the risk sequence mentioned earlier, risk management needs to be implemented. This is a much broader area than I initially anticipated. I have never worked with risk management in such a structured manner before. It will be interesting to apply this models to the actual project and try to create a risk free development environment. Security and risks go hand in hand. In order to avoid risks we strive to build a secure and robust product. The security aspect is involved in both the planning state and the product s afterlife. How to build secure software is an art in itself, I wish I knew more about this broad field. How do we predict risks we did not knew existed until they occur? The testing state is where the development team hopefully find these potential risks before putting the product in the hands of the customer.

5 A project is complete when it starts working for you, rather than you working for it. - Scott Allen THE FINISH LINE Everyone has ideas, few people do something about them. Working together in a team takes a lot of effort and the motivation needs to be high in order to reach the whole way to the finish line. Although models and methods are a great way to keep track of progress and actually move forward in a project, I think it is important to have some distance to it as well. Drowning in documentation and strictly sticking to models might make you forget the initial goal. Forgetting the initial goal might make you lose motivation and interest in even completing the project. On the other hand, an extremely free development strategy might make you lose track completely and float away towards a product that has very few similarities with the original goal. Project management is truly a tightrope, we are all struggling to walk without falling neither to the right or to the left. Do we ever find the perfect balance between structure and creativity? BIBLIOGRAPHY Litterature: Software Engineering by Shari Lawrence Pfleeger and Joanne M. Atlee 4th edition, Pearson Lecture Slides 1-5 for TNM090 by Karl-Johan Lundin Palmerius Linköping University Quotes: