Richard Stallman one of the computer industry's most outspoken defenders of open software, doesn't like Chrome OS.
Stallman, founder of the Free Software Foundation, continued to speak out against the notion of cloud computing today, telling The Guardian that the notion of Chrome OS' cloud model might better be described as "careless computing" than as cloud computing. Chrome OS is loosely based on a project near and dear to Stallman's heart--GNU/Linux--but "it is delivered without the usual applications, and rigged up to impede and discourage installing applications," he said.
Critical Chain Method (CCM) concepts where first introduced by a paper written in 1984 by Goldratt ("The Goal" – ed. Gower). The main factor for the success of this ideas is that it finds solutions to the classical problems we encounter once we plan following the Critical Path Method (CPM) approach.
CCPM (critical chain Project Management) is basically a mix of the most recent best practices:
PMBOK: Plan & Control.
TOC (Theory of Constraints): Removal of bottleneck to solve system constraints.
Lean: Remove waste.
Six Sigma: Reduce any deviation from optimum solution.
The problems
Going back to CCM, the main problems it aims to solve are:
Over estimating
This is a problem that usually comes up when defining plans. In a few words, since:
estimation are always cut,
details, at the beginning of a project are not always clear;
tasks that have the biggest uncertainty are sistematically over-estimated. We create contingencies, to protect us from the fact that things we don't know will go wrong. This process is then amplified because estimationa are presented to many stackeholders, at many levels, and often each level put its own contingency so that at the end the project duration (& cost) is usually over estimated.
Student Syndrome.
This happens in case of long projects or loose schedules: usually people will start working on a task not when planned but when the delivery time will be near. The reasons are linked both to the other issues we are presenting here (multitasking, parkinson law) and simply psychological: people will not start working till they will not fell the pressure.
Parkinson’s Law.
This is a notorious empirical law (Work expands so as to fill the time available for its completion) in Project Management.
In other words if you assign 15 day to accomplish a task that can be done in 10, then it will hardly happen that the work will be completed in 10 day, but macigally it will be completed in 15. Evidences of this law are well known to PMs.
This article is following the one where I highlighted some attention points to take care when changing job, but it specifies the aspect in relation to a team of IT professionals.
Here I would like to focus on the importance of a vision, an idea a final point which will drive us to what we want to reach with the team.
I would like to stress that creating your own vision is a fundamental task which usually takes a lot of time and involves both personal (what gives me the highest satisfaction in my work) and professional (where i want to be) aspects. Additionally this isn't a static process, but it will be normal that your vision will change as your career and personal life will progress.
Our own vision will be the result of a personal work, that we will build during or after the analysis of the situation where we will be working. However this is not enough, our idea of what we will be must be shared with our team and (most difficult) it has not to be against the one of our company. For this reason after a personal work, we must follow with a confrontation phase with our bosses and our team.
A good practice is to discuss first with our executive and then keep one or two brainstorming session with our team, later we will close the sessions with a clear commitment for getting the objectives that were agreed.
This means that some criteria will need to be satisfied in order to start a phase and some other will need to be satisfied in order to mark the phase as completed.
Very often we care about the requirement to start (entry criteria), but we do not give enough attention to the requirements that mark the end of a phase (exit criteria), unless they were specified within the contract.
Not being able to respect or not fixing correct exit often causes problems to the later phases or, even worse, if many teams are involved: for example when the development team gives control to the maintenance team it is really important that the documentation respects strong requirements in term of quality, in case not, even the easiest change will imply the analysis of the source code, which can be a really time consuming practice.
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.
If we must take responsibility of a project or we are involved in it, we need to get all the possible information and, most of all, we must check what is written within the contract (milestones, deliverables, SLA, exit criteria, responsibility areas ... ). Usually ignoring some clauses or even paragraph of the contract may lead to fatal consequences.
We need to immediately create log of deliverables/tasks that we are requested to accomplish. By creating such log we will be able to have quickly an idea, maybe not so precise, of the situation we are facing. A good starting point is usually the work plan (if it exists), but also interviews with team member and other stakeholders (avoiding however any kind of scope creep). Please note that the work plan (or better the project management plan) must always exist, what we need to do here is to move from the activities on a document to a better control of what we are doing and whar we are going to do.
