These are my point of attention to understand what is the “status of art” of a team/IT organization:
- Project control and Planning
- How do you do plan, do you follow any methodology?
- What tools do you use when planning?
- How do you perform project control?Are you using EVM (Earned Value Methodology)?
- Are there common plans among team?
- Does a time tracking system is on site?
- Are there any formal milestones during the software lifecycle, where a phase is closed and a subsequent is opened?
Continue reading Maturity of an IT development group
One of the most important models coming from the Waterfall model and developed to solve its problems, is the Incremental model.
With this model the we overcome the two biggest problems of the waterfall that are the possibility to see the product working without waiting the end of the project and the possibility to act on the design and the functions even after the development started.
In this model the product is designed, developed, integrated and tested in a succession of “increments” (usually called “releases”). This model is probably the most popular in case of complex development when large groups are involved.
Within this method, we start from a complete initial design of the to-be system and then we define:
- the independent parts
- the primary functions, in relation to other functions that need the “primary” ones to work (e.g. before calculating the interest on one account you should have already working the function of movement archival)
- the release plan
- the integration plan
It’s clear from the description that first the basic functionalities will be released and then, at well defined intervals of time, all the others which at the end will give the finished product.
Continue reading Incremental Model
In order to create a common vocabulary, in my first article i will recap the nine Project Management areas.
According to the Project Management Institute (www.pmi.org), the defining resource on all things related to project management, project management is centered on nine knowledge areas. Events in each knowledge area affect what happens in the other eight knowledge areas.
Continue reading PM areas … a refresh
Earned Value Analysis in the last years proved itself as one of the best system for project control. It’s importance comes from thefact that we get an integrated vision checking both costs and schedule.
In this article, I will try to introduce the EV concepts. This introduction should help you to apply straight the EV to your project.
Before start with the definition, pleast consider that EV in its correct form would require all the quantities being expressed in term of money. Quite often this is not possible (expecially in large organizations) because such values are not shared with team leaders or because it is difficult to get them. In order to apply the EV concept we just need to substitute the “money” with “person day”. Even if in this way we loose a bit of information related to project indirect costs, the results in term of control are still relevant.
The most important variables in EV analysis are:
- BCWS (budgeted cost of work scheduled) or PV (planned value)
it represents the initial estimation for one activity. It’s the cost of the activity if it is done as planned. If there are no planned cost, then we used planned days.
- BCWP (budgeted cost of work performed) or EV (Earned value)
Continue reading Earned Value in brief
In this article I’m going to list a number of practical action to consider when we take leadership of a new team or join as manager a new project. I assume planning is one of the most important thing, so I didn’t stress a lot about it. Here I preferred to emphasize on the “soft” aspects that usually we acquire only with experience.
For the sake of shortness, I wrote the article as a check-list. If needed i will expand the single themes in other articles.
I wrote this list thinking about a team involved in IT work. Nevertheless, I hope that it will be possible to grasp some positive ideas also if the team will be involved in other areas.
Continue reading How to organize a new IT team
It can happen that an IT manager will be responsible for a maintenance service.
During this activity it may happen that he/she will have to handle emergency situation, that can be caused for example by wrong production releases, problems in test environment, problem in development environment, till in the worst cases production problems.
I’m presenting here a series of actions that may be useful when we need to manage such “nasty” situations.
As first step: try to calm down yourself and the people involved
The worst thing in such cases is to act based on our emotions: there might be an angry costumer and we will try to do everything to set up the situation. In this moments it is important to calm down and do not act based on our impulse, in order to avoid making the situation even worse. Sometimes the best thing is to leave the communication with customers and client to a senior manager or to someone less involved in the problem. If someone working for you is managing the situation, try to calm him/her down and maybe consider that you can handle the communication with the client.
Evaluate the problem in relation to the project and if possible classify it
It may be that who reported the problem didn’t evaluate it correctly or has a dramatic vision of the impact. We should try to obtain the maximum information and to understand the impact of what happened. We need to get rid of all the assumption that people around us are doing and we need to go back to the facts. At this point it will be possible to define the priority of the problem (sometimes it is done automatically) and the causes that originated it.
If needed (and possible) apply a workaround to get the situation to a stable condition.
You will apply this option only when it is needed to get online again an high priority service. If possible so we will apply or suggest workaround that give back the functionality, even if not at 100%. Careful – sometimes a workaround che cause even more damage than the original problem, so before applying it, you should always discuss with the service manager. Just as an example, if the problem was caused by a wrong software change, by using the normal change management tool, is usually possible to get the software (!! but sometimes not the data!!) back to what it was previously.
Continue reading In case it happens …
A checklist, good for checking that all cost are planned, when developing the financials of a project plan.
- Does the financial plan define the expected monthly cash flow as the basis for monitoring the project’s financial performance?
- Does the financial plan include an appropriate allowance for risks and contingency costs?
- Does the financial plan base reflect the staffing profile over time and calculate costs at that level (e.g., number of people multiplied by the time they are charged to the project)?
- Does the financial plan use an appropriate rate for each type of resource (e.g., an assumed average rate, specific rates for known individuals on the project team, or a combination of the two, depending on company policy)?
- On larger projects, does the costing model include a rate and salary adjustment factor for future years?
- Does the financial plan document all assumptions with respect to the cost rates along with the other assumptions on which the estimate is based?
- Has care been taken to avoid adding contingency on top of contingency (i.e., contingency should be provided for only once and managed separately from the activity/task level estimates)?
- Does the financial plan include other related costs such as overhead, travel, and other expenses?
- Was consideration given to including a start-up budget allocation to cover the costs of getting the project started such as setting up a facility and hiring or relocating staff?
- Has everything possible been done to minimize the elapsed time between when the work is performed and when payment is received (where applicable)?
- Has everything possible been done to obtain progress payments rather than payments based on acceptance of deliverables (where applicable)?
- Has everything possible been done to avoid holdbacks on milestone payments (a 15 percent holdback payable upon completion means that the project may not make any profit until the holdback is paid)?
- Where subcontractors are involved, does the financial plan make sure that a subcontractor does not get paid for a deliverable by us until we get paid for that deliverable by the customer?
The following is a check list that should help us to understand how much we can trust to our estimation and what is the probability of having later problems.
- Was a tool or an estimating spreadsheet used in preparing the estimates?
- Were multiple estimators used to generate independent estimates?
- Were the estimators experienced in preparing estimates in this kind of situation?
- Were the estimators experienced in the technology to be used?
- Was task-based estimating applied to generate bottom-up estimates?
- Were the estimates compared with rules of thumb and other sanity checks? If yes were they consistent?
- Did we review the estimation coming from independet sources and did we understand the and rationalize differences?
- Did we checked the initial assumptions on which the estimations are based?
- Have the assumptions been validated with the customer?
- Were the estimates balanced through a process of understanding and rationalizing the major differences between the preliminary estimates (rather than taking the lowest estimate)?
- Did the estimates assume average productivity rates (rather than maximum), which take into consideration the specific circumstances on this project that will impact upon productivity (e.g., working off-site versus working on our premises)?
- Was the final estimate the result of a consensus reached on a reasonable, balanced estimate that all concerned could accept?
- Has the final estimate been reviewed by some one external to the project, which is familiar with productivity and cost data from other similar projects (historical and/or current)?
- Did we take in account of the activities that often are not considered in tools, as not linked to real development but linked to the project type? Following a list of such activities. Usually part of them is estimated in the project contingency, while other points are estimated specifically (for example change management or quality), however by experience often we do not consider some parts that then lead to an unplanned cost raising and/or to scheduling issues.
- Interaction with users and clustomers
- Software Demo
- Revision of planning, estimation, code …
- Tool Installation and Maintenance
- Preparation and Maintenance of test environment
- Change management
- Quality management
- Explanation of documents
- Support to other project/subprojects
- Technical revision
- Work in tiger team
- Training on-the-job.
Following is my list of hints you can use to ensure your projects or the projects you are assigned to lead, are well managed and run:
- Work plans – does the team operate under work plans that are based on a proven methodology and estimated with a proven estimator? First, is there a detailed work plan showing deliverables, tasks, estimates, assumptions, schedules, and resources you can review? If there is not, this needs to be addressed as a top priority. Projects that try to operate without a detailed work plan run large risks of not meeting client expectations, and ultimately, not delivering on time, on budget, and on scope. Also, as a part of the detailed work plans are the key milestones and dependencies identified, documented, and understood by the team.
- Time reporting – does the team do weekly time tracking against the aforementioned detailed work plans? Once a detailed work plan is in place, the next step is to actively track work efforts against the work plans. Periodically time tracking against planned tasks and deliverables is a must to ensure the plan is being followed. If time spent is tracking correctly and plans are good, then we will have available metrics such as:
- the Cost Performance Indicator (CPI), which reports the value of days earned in the planned against days burned (spent),
- the Schedule Performance Indicator (SPI), which reports the value of scheduled days earned against calendar days burned (spent)
We will see in another article, that if either the CPI and/or the SPI are significantly under, or over, a value of 1.0, then you should be looking into the work plans, the estimates, the skills on the team, scope management, and/or the addition of unplanned tasks to the project. Continue reading Assessing the status of a project
To reach high quality levels, when developing and maintaining software it’s needed to develop, maintain and improve processes, as well. Better work processes result in better work products, where “ better work products ” means enhanced features, improved quality, less rework, and easier modifications.
Here are the basic principles to follow:
- Work processes must be designed with the same care used to design work products; work processes must be designed to satisfy process requirements and process constraints, fit the needs of individual projects, and make the work processes efficient and effective.
- Work processes for each project should be derived from a process framework. A process framework is a generic process model that can be tailored to meet the needs of a variety of situations. The tailoring of a framework involves adding, deleting, and modifying elements to adapt the framework to the needs of particular projects.
Process design and process improvement result in shorter schedules, higher quality, lower costs.
We should however notice that process improvement seldom happens spontaneously: a positive ROI (return on investment) requires an ongoing investment of time, effort, and resources
It is however important to stress on the second of the points above: processes must be designed and tailored to the specific needs and not taken and adopted from some best practices of other organizations, without an adequate analysis.
Process design is best accomplished by tailoring and adapting well known development process models and process frameworks, just as software design is best accomplished by tailoring and adapting well – known architectural styles and architectural frameworks.
The following general principles applies:
- There are several well known and widely used software development process models, including Waterfall, Incremental – build, Evolutionary, Agile, and Spiral models.
- There are various ways to obtain the needed software components; however different ways of obtaining software components require different mechanism of planning, measurement, and control.
- The development phases of a software project can be interleaved and iterated in various ways.
- Iterative development processes: provide the advantages of
- continuous integration,
- iterative verification and validation of the evolving product,
- frequent demonstrations of progress,
- early detection of defects,
- early warning of process problems,
- systematic incorporation of the inevitable rework that occurs in software development,
- early delivery of subset capabilities (if desired).
- Depending on the iterative development process used, the duration of iterations range from one day to one month.
- Prototyping is a technique for gaining knowledge; it is not a development process.
- Always remember that mechanisms of planning, measurement, and control used in a software project are strongly influenced by the development process used.
- SEI, ISO, IEEE, and PMI, provide frameworks, standards, and guidelines relevant to software development process models