10 ways to avoid mistakes during project development

A lire sur:  http://www.techrepublic.com/blog/10things/10-ways-to-avoid-mistakes-during-project-development/1360

By Alan Norton

February 22, 2010, 12:11 PM PST

The best strategy for dealing with mistakes is to avoid making them in the first place. Here are some tips to help you navigate around common project pitfalls.

---

You may have heard the phrase “Be proactive, not reactive.” It’s certainly appropriate when discussing how to best deal with mistakes. The idea, of course, is to prevent mistakes before they occur. But how exactly do you do that?” In this article, I will detail 10 real-world ways you can preempt mistakes during project development.
For the sake of simplicity, I’ve lumped all errors into one category: mistakes. The items listed here are specific to developers, but other IT roles can also benefit from many of them.
Note: This article is also available as a PDF download.

1: Learn from other’s mistakes

Find experienced peers who are willing to share their mistakes and then learn from them. I am somewhat biased, but the editors, writers, and members of TechRepublic seem willing to honestly share their mistakes — even if somewhat embarrassing at times.

2: Do your research first

No matter how much you know, you’ll encounter new challenges on an almost daily basis. Each challenge usually requires you to learn something new. Before you tackle a problem or task, do your homework. The trial-and-error method of learning may have been necessary and acceptable years ago. But with the resources available on the Internet today, there is little excuse for mistakes made because you didn’t do the proper research in advance.

3: Have a plan

You can’t know how to get to your destination without a roadmap. In project development, that roadmap is known as a project plan. Whether done formally or informally, you need to know how to get where you are going. Days or even weeks of programming time can be lost if the wrong path is taken. When done the right way, a project plan will help keep you from straying off course.

4: Follow standards and use templates

There are good reasons why experienced professionals took the time to create and publish industry and company standards. Standards detail best practices and procedures learned over years of trial and error.
Templates such as predefined forms can be useful since most of the work is already done in a standard format. A standard EULA approved by your legal counsel is another good example of a template that can come in handy if you are developing application software. A mistake in a legal document can be an expensive exercise — one best avoided.

5: Communicate and coordinate with others

If you are part of a team, it’s essential to communicate with other team members to avoid redundancies and to coordinate your work with theirs. Emails, instant messages, project status reports, and teleconferences are all ways to communicate and coordinate with others on the team. Unfortunately, each of these is far from perfect. You can spend the better part of a day reading and writing emails, participating in conference calls, and instant messaging with your peers. But it is a necessary part of the development process.
The perfect tool for communicating and coordinating with others in a team environment has yet to be developed. One of the better tools developed to share code is revision control software. Your project may also benefit from the use of a communication plan that ensures everyone involved — including customers and stakeholders — is kept apprised of key developments. (The TechRepublic downloads library has a free communication plan template to get you started.)

6: Allow enough time

It was at Hughes Aircraft Company that I first heard the phrase “You want it bad - you got it bad.” It didn’t happen very often, but when it did it was almost always made in reference to a part from a vendor that was badly needed, rushed through production, and upon arrival, failed testing. Failure to allow enough time for each phase of the project can lead to missed requirements, inadequate analysis, poor design, rushed programming, insufficient testing, and incomplete documentation. The result can be a system that doesn’t meet expectations and fails in one or more key areas.
Estimating the time needed to accomplish each phase of a project is difficult. I achieved the best results when I sat down with my supervisor and determined the time allotted for each major task in the project plan. I was overly optimistic in my estimates. He was much more realistic in his estimates, and he turned out to be right. As a rule of thumb, doubling my initial estimates came close to the actual time required. That information was useful for developing project plan timelines.
You may need to develop a similar rule of thumb until you can more accurately estimate completion dates. Ideally, you want to complete each phase of the project on time, and the best way to do that is estimate them correctly up front. Here are a few tips on creating realistic schedules.

7: Reuse proven code

If you’re an experienced developer, you should have built up a large code base over the years. Go blue and recycle this code whenever possible. You will likely have to modify the code to fit the new requirements, but proven core code is a good foundation to build on. Not only will you reduce the risk of introducing new bugs, but you will eliminate the time wasted creating similar code and the subsequent testing required.
Share your code with others so they can reuse parts of it. Proven code can be shared via plug-ins or libraries. Good external sources of code are available on the Internet that can be legally used for free or for a small fee.

8: Use checklists

Before a commercial plane trip, the pilot and co-pilot are busy walking through a long, detailed checklist. Checklists can be used during various phases of the project development process. They are particularly useful when working with large systems and when a single person is responsible for multiple tasks.
For example, a list detailing the steps required for system turn-on will help avoid accomplishing tasks out of order and prevent errors of omission. It is all too easy for developers to overlook important items like system access when they are busy doing final testing and documentation.
For more on the virtues of using checklists, see Leverage checklists to improve efficiency and client satisfaction.

9: Test, test, test… and carefully review your work

There is a healthy level of paranoia about delivering error-free work. Test as much as possible as early as possible. Errors in the code are typically more expensive to correct when found near the end of the development process. The last thing you need when facing a critical release date is to find a bug that should have been found months ago.
Careful and thorough testing will allow you to find those mistakes before your users can. Double- and triple-check your work. Develop test data and a plan to test common calendar-based events like EOM processing and annual reporting. All functionality and every single possible scenario should be thoroughly tested. And, yes, this is also a good place to use a checklist.

10: Test again with a third party

Find at least one experienced person who can be dedicated to the beta testing. They will undoubtedly use the system in ways you never dreamed of and find bugs you missed.
Don’t overlook or rush this final quality assurance task. It’s typically your last chance to get it right. Once a bad piece of software is released or a system with a critical bug is turned on, a company’s image can be tarnished for years to come.

The final word

One of the most important lessons I learned very early in my career is that a mistake isn’t a mistake until someone else knows about it. I was but a young inexperienced pup when I accidentally deleted some system files on a Tandem PC. It could have been a disaster. But I had enough sense and problem-solving skills to identify and copy over the missing files from another Tandem PC.
I have never told anyone until now about my near disaster. This may be obvious, but you should keep unseen mistakes to yourself. There is almost never anything to be gained by telling others you have done something really stupid. It can negatively affect your image and possibly damage your career.
I hope these proactive tips will help you avoid making an embarrassing mistake that becomes known to your boss, peers, and users. If you find yourself in that unenviable situation, you might want to read Calvin Sun’s article 10 things you should do if you make a big mistake.
I have always learned the most from my mistakes — but I prefer not making them in the first place.

Prenez garde à ces erreurs d’estimation courantes

A lire sur:  Tenstep

Le processus d’estimation est à la fois un art et une science. Cependant, une fois que vous avez appris de bons processus et techniques d’estimation, vous serez, heureusement, plus attiré par le côté "scientifique" de l’activité d’estimation que par son côté "artistique". Vous pouvez devenir plus fort en matière d'estimation, mais, par nature, vous ne serez jamais parfait. Nous vous présentons ci-dessous une liste de problèmes d’estimation courants qu’il est important d’éviter :

·         Ne pas prendre la totalité du travail en compte. Il s’agit d’un problème très courant, affectant surtout les premières estimations globales. Vous pouvez par exemple oublier un travail important que vous n'aviez pas perçu comme faisant partie du projet, tel que la documentation ou la formation. Généralement, cependant, vous sous-estimez la taille des livrables à réaliser ou bien vous n’incluez pas toutes les activités requises pour réaliser les livrables.

·         Prendre ses désirs pour la réalité. Tous ceux qui ont effectué des estimations de travail connaissent la pression que peut exercer le client pour obtenir les estimations les plus modestes possibles. À la limite, le client souhaite obtenir ce qu'il veut avec le moins d'effort (et de coût) possible. Assez souvent, l’estimateur a tendance à se laisser envahir par cet état d’esprit. L'estimateur finit par « souhaiter » que le travail soit réalisé conformément aux attentes du client.

·         Ne considérer que le meilleur scénario possible. Le client insiste pour que tout soit produit le plus rapidement possible. Votre manager le suit. Et vous aussi, et une réalisation rapide vous semble possible. Cependant, vous rencontrez des difficultés, parce que vous ne considérez que le temps nécessaire pour achever le travail si tout fonctionne adéquatement. Vous essayez de penser au travail en termes de fourchette, mais vous finissez par vous engager dans une estimation se situant au niveau le plus bas ou le plus optimiste de la fourchette.

·         Se croire, à tort, capable de livrer un travail de haute qualité. Ce problème est lié à une estimation basée sur la confiance de pouvoir atteindre un certain niveau de qualité dès la première fois. Cependant, lorsque le projet avance, vous comprenez que votre capacité de produire à un haut niveau de qualité est limitée. Cela finit par entraîner encore plus de travail de reprise, de résolution de petits problèmes, de nouveaux tests, etc.

·         S’engager à se conformer au budget disponible. Dans ce cas, le client dispose d’une somme fixe pour le budget. Le chef de projet pense qu’il y a une chance de terminer le travail dans les limites du budget disponible et il s’engage donc à respecter cette somme. Ce problème est similaire à celui exposé plus haut pour le meilleur scénario possible.

·         Ne pas reconnaître les penchants qui influencent l’estimation. Il s’agit ici des préjugés qui ont tendance à se glisser constamment dans vos estimations. Certains sont optimistes, d’autres pessimistes.

Les penchants optimistes poussent à sous-estimer le travail et peuvent inclure les cas suivants:

·         avoir tendance à penser que le travail sera aisé;

·         avoir tendance à penser que votre équipe est en mesure de produire davantage de travail qu’elle peut le faire en réalité;

·         ne pas prendre en compte les risques du projet, les problèmes majeurs, les défauts de communication, etc.;

·         avoir tendance à adopter un point de vue optimiste au premier abord.

Les penchants pessimistes entraînent une surestimation du travail et peuvent inclure les cas suivants:

·         vous avez eu une mauvaise expérience avec un projet similaire dans le passé;

·         vous ne voulez pas vraiment de ce projet : vous donnez des estimations fortes en espérant que le projet soit annulé;

·         avoir tendance à commencer à émettre un point de vue pessimiste.

Vos penchants sont toujours présents. La manière d’agir consiste à les reconnaître pour les combattre là où vous les remarquez. Cela vous aidera à préparer des estimations aussi valides que possible.

Terminologie de management de projet

Plan de management des coûts. Document qui définit le format à utiliser, les activités à effectuer et les critères à respecter pour planifier, structurer et contrôler les coûts du projet. Ce plan est inclus dans le plan de management du projet ou peut y figurer comme plan subsidiaire. Aussi appelé Plan de gestion des coûts dans certains pays francophones.

Planifier les approvisionnements. Processus qui consiste à documenter les décisions d'approvisionnement du projet, à spécifier les approches et à identifier les vendeurs potentiels.

Abréviations courantes

IFB (anglais) : Invitation for Bid

       (français) : Appel d'offres

How to Manage Project Risks

A lire sur:  ProjectManager.com

Managing risks always seems so complicated, but it doesn't have to be that way. To show you how to simplify your risk planning on projects, read on to learn...

Here's the scenario. You just bought a brand new car! It's the car you've been wanting for years and there it is, tucked safely away in your garage. It will be fun to show everyone at work the next morning. At the thought of parking at work, you become concerned about the paint getting scratched. What options do you have in dealing with this risk?

Accept the Risk of Your Car Being Scratched
An obvious response is just to accept the risk. It won't change what time you go to work or where you park. You will just hope that nobody parks too close or rubs up against your brand new car. In the event that somebody does scratch it, you'll cross that bridge when you come to it. Before that, you're not even going to think about it.

Avoid the Risk of Your Car Being Scratched
Don't like the idea of accepting the risk? Another choice is to avoid the risk altogether. You can do this by not going back to work, and keeping the car in the garage. Never letting your car see the light of day will nearly guarantee that your car won't be scratched.

Mitigate the Risk of Your Car Being Scratched
If avoiding risk is not an option, you could just lessen the chances of the risk occurring. Rather than leave your house when the traffic is the heaviest, you could leave an hour later to put more space between you and the cars around you. When you do make it to work, you could also park WAY over in the corner about a mile from the office where nobody else parks. Both steps would greatly reduce the risk of your new car being scratched.

Transfer the Risk of your Car Being Scratched
A final choice is to put someone else's car at risk of being scratched. That's right, call a taxi! You can pay someone else to remove the risk to your new car, and transfer it to someone else. They can decide how they want to handle the risk.

The bottom line is that you have choices in how you respond to risk. The choices you make will be commensurate to the level of risk you are willing to take.

You can do the same thing with all the risks associated with your project. Ask yourself how you will deal with each one, and which ones you are willing to accept. This will leave you with a short list that you'll need to have plans in place for if they do occur.

When to use functional programming languages and techniques

A lire sur:  http://www.techrepublic.com/blog/programming-and-development/when-to-use-functional-programming-languages-and-techniques/6801

By Claudio Caballero, May 21, 2013, 10:30 AM PDT

Takeaway: If a project requires lots of concurrency/parallelism, its own language, or lots of math, you should think functional programming.

As IT professionals, we have to balance proficiently executing on current projects with proven technologies and learning to implement new ways of doing things. Software development arguably changes more rapidly than any other aspect of IT, making it an even tougher challenge.
Given the limited amount of time, it’s often difficult to decide what new techniques to learn. The questions of if and where to use functional programming languages/techniques strikes me as one of the tougher calls to make these days.

If and where to use functional programming

First, let’s define our terms. A functional language or technique is one in which the sole or dominant form of expressing algorithms is the evaluation of mathematical functions, avoiding state changes and mutable data. This is as against declarative, imperative, and procedural languages/techniques, which emphasize changes in state.
There is a strong case to be made that either functional languages or the other kinds can be object-oriented. LISP, considered by many an archetypal functional language, is a prime example. In other words, you can use either kind of language to implement object-oriented principals (and some would argue, more “purely” in functional languages). Similarly, you can write bad code in any language.
So, what kinds of problems are functional languages (if used well) superior at solving? Surveying the literature, problems that require lots of concurrency and parallelism jump out as obvious candidates. Erlang, for instance, was used prominently at Ericcson in the telecommunications equipment field, and more recently to power messaging startup WhatsApp. Interestingly, the famous Lucent (via Western Electric, not Bell Labs) 5ESS telephone switch is another example of a prominent functional programming success story. If you’ve placed a phone call to or in the United States in the last 30 years, chances are you used one of these devices, and the code that keeps its database (with more than 1,000 relations) consistent, was written in a custom language called Pdiff, which in turn was written in Standard ML.
That brings us to another area where functional languages seem to shine: domain specific languages (DSLs). If your problem domain is so hairy that the usual design patterns we’re used to in typical enterprise languages like Java and C/++ fail to efficiently solve them, a DSL might be just the trick. You wouldn’t build your whole system with a DSL, but, like the 5ESS switch, you could use it to code a critical function in a way that is easier to understand and maintain and, therefore, ensure its quality. Functional languages are killer at creating DSLs.
One interesting example I found is a DSL to process exotic financial derivatives. This illuminates another area where functional languages/approaches shine: math-heavy algorithms. If you need to solve a problem that can decompose into a series of mathematical operations, the kind of thing you’d tackle with a DSP chip or GPU, then a functional language is likely a good choice for expressing the solution.
Another way to think about this kind of problem is: Could you solve it, at a small-scale, with a spreadsheet? If the answer is yes, then you’ve got two choices: get a product that can compile spreadsheets into your platform of choice (many exist), or express it in a functional language. This is a useful analogy, because it highlights how functional languages (which seem so math-centric) can handle operations we’re used to in other languages, like conditional statements. If you’ve ever used the IF function in a spreadsheet, then you have your answer. Functional languages, like the other kinds, are Turing Complete, and can be used to code any problem. The trick, it seems, is to code different parts of your system in languages that are most effective at expressing that part of the problem domain.
Great, so, I’ve got you interested in functional programming, now what the heck do you? When trying to build a new capability within my team, my preferred approach is to identify a potential pioneer. Someone who can grok the new ideas, drink the proverbial punch, and then bring that knowledge back to the team and evangelize. Send that person out for training, and then (as I think you should do with any training course) have them share what they learned with the team (buy them all a meal at the same time too, it helps). But only do so when you’ve identified a project or task where a functional approach makes sense. If folks don’t start to use what they’ve learned within 30 days, it’s likely gone.
If you want to incorporate functional code into your larger system, one approach is to have the language compile into the same bytecode as your main system; Scala runs on JVMs, and there is F# for the .NET CLR (and other platforms). You can always just run your code in one of the other functional language environments (such as Haskell, Clojure, OCaml, etc.) and expose it with a REST API as well.

The bottom line

If a project requires lots of concurrency/parallelism, its own language, or lots of math, think functional programming.

Article discussion

I’m coming at this issue from the perspective of someone who has been managing software development for over 20 years. I’m focusing on the questions: “Does this tool belong in my toolbox?” and “What kind of problems can I fix with it?” I hope the related discussion doesn’t devolve into the near religious fervor that often accompanies discussions about which programming language is better for what application.

Four Steps to Show the Value of Training

A lire sur:  Method123

Many businesses struggle with whether they are getting their money’s worth in sending employees to training classes. This question can be applied to project management training as well as any other type of business training. You know the cost side of training too well. But how do you tell what the business value is?

The most common way to determine value today is to ask the trainee whether he or she thinks the class was valuable. This is very touchy-feely and doesn’t give you much information to go on, but it is probably the most that most companies ask in terms of follow-up.

A Rigorous Approach

There is a process to more rigorously determine the value received for your training dollars. These ideas are not for the faint of heart. They take more preparation and they take more of that most precious commodity – time. But see if it makes sense, and whether the results of this process will give you a much better feel for the value that you are receiving from training. You can also start with some of these steps, and try for the rest later.

1. First, the trainee and their manager meet a few weeks before the training is scheduled to make sure the trainee is ready for the class. One of the important parts of the discussion is to identify opportunities where the trainee can apply the new skills on their job. This information should be documented so that it can be compared with a post-class assessment done later.
2. When the actual class begins each of the trainees should complete an initial survey showing their specific knowledge level of the class material.
3. A week or two after the class, the trainee completes a post-class survey showing their current knowledge level in the subject. For the most part, it is exactly the same as the initial survey from activity #2 above. This is compared to the initial survey to provide a sense for how much the trainee learned - at least in their own opinion. If this survey comes out close to the original version, it may show that the training may not have been very effective. You would expect that the post-class survey would show improvement.
4. Here is the key step. A few months after the class, the trainee and their manager meet again for a post-class assessment, which is a follow-up to activity #1 above. In this discussion, the trainee and manager discuss the value of the class, and whether the trainee has been able to apply the new skills. In fact, the training may have been superb, but if there have been no opportunities to apply the new skills, then the business value will be marginal. The trainee and manager can then discuss the business value that was gained by applying the new skills on the job.

Summary

In most training classes today, the trainee completes the class feedback for the benefit of the training company, and then tells his or her manager how good the class was. This superficial feedback is all that is available to gauge business value. However, the real test of business value is whether the class resulted in an increased skill level that can be applied to the job to make a person more productive. This cannot be determined immediately after a class. The only way to determine business value is to determine in the months after the class whether or not the training has actually been applied on the job. If you capture this information on all your classes, you will get a much better and more fact-based view of whether the classes you pay for are providing business value to your company.

N°175: Valider l’estimation du travail avec l’équipe

A lire sur:  Tenstep

Une des responsabilités fondamentales d'un chef de projet est d’élaborer un échéancier de projet et d’assigner des activités de l’échéancier aux membres de l’équipe pour exécution. Après avoir réparti le travail aux membres de l'équipe, vous devez leur faire porter la responsabilité de la réalisation du travail conformément aux attentes.

En surface, cela sonne très sévère et très sec. Cependant, est-ce vraiment juste? Montons d’un cran. Supposons que vous êtes le chef de projet et que vous êtes affecté à un projet une fois que l'estimation de l’échéancier et du budget a déjà été réalisée. Cela ne vous paraît pas juste, puisque vous n’avez pas pris part à l’élaboration des estimations. Vous pensez probablement que si vous êtes tenu responsable de l’échéancier et du budget, vous devriez être impliqué dans leur élaboration.

Voyez maintenant le problème qui se pose à l’occasion de l’assignation du travail aux membres de l'équipe. Est-il juste de leur faire porter la responsabilité du travail s’ils n’ont pas participé au processus d’estimation? La réponse est également "non".

Il y a deux manières de s'assurer de la confiance des membres de l'équipe dans le cadre des estimations relatives à l’échéancier et au budget. La première est de voir si vous pouvez mobiliser les membres de l'équipe autour du processus d’estimation préalable. Ce n'est pas toujours réalisable, mais c’est parfois possible. (En fait, vous pouvez avoir besoin de l'aide des membres de l’équipe du projet pour élaborer réellement le budget et l’échéancier avec lesquels vous allez démarrer). Si les membres de l'équipe prennent part au processus d’estimation, ils peuvent être tenus pour responsables de la réalisation des travaux conformément à ces estimations. (Si les membres de l'équipe sentent qu'ils ne peuvent pas être tenus responsables des estimations qu'ils ont aidé à mettre au point, alors vous devriez vous demander si les chiffres sont vraiment valides).

D’autre part, dans beaucoup de projets, les membres de l’équipe ne sont affectés que lorsque l’échéancier du projet est déjà en place. La personne qui a élaboré les estimations initiales doit émettre quelques hypothèses au sujet du rendement « moyen » des membres de l'équipe et faire des estimations fondées sur ces hypothèses.

Dans ce cas, il est judicieux de charger un membre de l'équipe de vérifier si l'estimation semble raisonnable. Vous ne recherchez pas une estimation avec un facteur de confiance de 100%. Vous êtes juste en train de voir si l'estimation de l’échéancier, de l'effort et du budget semblent raisonnables. Si le membre de l'équipe répond par l’affirmative, alors vous pouvez faire assumer à l’équipe la responsabilité de terminer les travaux conformément à ces estimations.

Naturellement, si vous assignez d'abord le travail, les membres de l'équipe ne sont pas assez informés pour juger si l'estimation est raisonnable ou pas. Cela peut prendre un peu de temps, alors qu’ils doivent réellement commencer à travailler sur l'activité. Et c’est aussi bien ainsi. Dans ce cas, vous assignez le travail en donnant des indications sur l'effort, le budget et le délai estimatifs. Vous demandez alors aux membres de l'équipe de confirmer si le travail peut être accompli selon ces estimations. Si les membres de l'équipe considèrent que les estimations sont incorrectes, ils doivent vous le communiquer AUSSI TÔT QUE POSSIBLE. Dans ce cas, le membre de l'équipe est obligé de fournir une estimation plus réaliste. Le chef de projet peut refuser d’admettre que la nouvelle évaluation est plus précise que l’ancienne. Une certaine négociation peut avoir lieu. Cependant, quand le membre de l'équipe et le chef de projet sont d'accord, le chef de projet peut tenir le membre de l'équipe responsable de son estimation.

L’essentiel dans ce scénario est que le membre de l'équipe, dès qu’il en est convaincu, doit notifier au chef de projet que le délai initial ne permet pas de mener le travail à terme. Il n'est pas acceptable que le membre de l'équipe attende que le délai d’origine soit dépassé avant d’affirmer que les estimations étaient mauvaises.

Ces approches sont une façon de faire porter aux membres de l'équipe la responsabilité du travail, tout en étant juste envers eux, en leur permettant de prendre part aux estimations et d’y adhérer. Une fois cette adhésion acquise, ils peuvent légitimement être considérés comme responsables du travail.

Terminologie de management de projet

Prévisions. Une estimation ou des prédictions de situations ou d'événements à venir dans le déroulement du projet, à partir d'informations et de connaissances disponibles au moment où les prévisions sont effectuées. Ces informations sont tirées de la performance passée du projet et de celle attendue par la suite, et comprennent des éléments susceptibles d'avoir un impact sur ce projet à l'avenir, tels que son coût final estimé et son coût estimé pour achèvement.

Problème majeur. Point à l'étude ou litigieux, en cours de discussion pour régler la question, ou pour lequel s'opposent des points de vue ou des divergences.

Abréviations courantes

ETC (anglais) : Estimate to Complete

       (français) : Coût estimé pour achèvement

Three Techniques for Scope Change Management

A lire sur: Tenstep

1. Hold Everyone Accountable for Scope Management

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, your customer may try to go directly to team members for changes.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. Your customer  must also understand the process and its importance. Don't consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

2. Use a Change Control Board for Large Projects

Sometimes on very large projects, the project sponsor does not feel comfortable making the scope change decisions alone. This may especially be the case if the effect of the change will impact other organizations. It may also be the case that multiple organizations are participating in, or contributing to, the project funding, and want to have some say in evaluating scope change requests. For these cases, a group of people might be needed to handle the scope change approval.

A common name for this group is a Change Control Board. If a Board exists, it may be more cumbersome to work through. However, the general scope change management process does not need to change dramatically. For instance, there is still a document for the initial the scope change request. The project team needs to determine the impact and cost to the project. The Board must consider the impact, the value to the project, the timing, etc., and then make a determination as to whether the request is accepted.

The Scope Change Procedures must be more sophisticated to account for the Board. For instance, you need to clarify who is on the Board, how often they will meet, how they will be notified in emergencies, how they will reach decisions (consensus, majority, unanimous, etc.), how incremental work will be paid for, etc.

3. Make Sure the Right Person Approves Scope Changes

A typical problem on a project is that the team does not understand the roles of the sponsor, customer and end users in the area of change management. In general, the project sponsor is the person who is funding the project. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. 

The people that the project team tends to work with most often are normal customers and end users. End users are the people that use the solution that the project is building.

It doesn’t matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change. The sponsor (or designee) must give the approval. The end users can request scope changes, but they cannot approve them. The end user cannot allocate additional funding to cover the changes and cannot know if the project impact is acceptable.

ANATOMIE D’UN EMAIL: La visualisation de l'email

A lire sur:  ContactLab

La clarté avant l’esthétique
Une fois que votre contact a ouvert votre message, comment le visualisera-t-il ?
Il décidera en quelques secondes si cliquer : le comprendra-t-il en un coup d’œil ?
D'une part les clients email interprètent différemment votre code html, d'autre part beaucoup d’entre eux n’affichent pas les images par défaut.
Votre message doit donc être optimisé pour tous les clients et en mesure de convaincre votre cible même si les images ne sont pas affichées.

	Testez le rendu sur tous les clients email N’oubliez pas les mobiles ! (on abordera le responsive dans un prochain épisode) Assurez-vous que les parties principales soient textuelles, en particulier les titres et les appels à l’action Utilisez des balises alt pour décrire toutes vos images Respectez un ratio texte/images d’environ 70/30

Are your tender requirements killing your IT project?

A lire sur:  http://www.techrepublic.com/blog/tech-manager/are-your-tender-requirements-killing-your-it-project/8286

By Ben Evans,  May 20, 2013, 6:23 AM PDT

Plenty of organizations have well-formed procedures for procurement on large projects, but when the projects are small, the contracts are short-term, or the budget is low, those same procedures can easily become a crippling overhead to both sides of the procurement process.
Whether you’re sourcing training, software, hosting or bespoke development, an RFT (Request For Tender) with unnecessary, unrealistic, or just over-the-top requirements can make it too hard for some companies to commit the time required just to do the paperwork. In extreme cases you end up with vendors that specialize in meeting tender requirements instead of specializing in the service they’re pitching to provide.
Here are my five tips for reducing the pain of running a tender process for smaller projects:

1. Focus on the outcomes not the how to’s

You may have a solution in mind when penning a RFT, especially if you’ve worked on similar projects in the past. However, treating the solution you’d expect as a requirement can be a mistake. Remember that the whole point of a tender is that it lets suppliers pitch on price and solution. Concentrate on the specific outcomes the project has to achieve and the standards that need to be met, and leave the “how” for the vendors to figure out; it’s their job anyway.

2. Avoid legacy and CYA requirements

Be careful of setting standards and requirements based on past vendors rather than the current project. It’s easy to do and not always deliberate as people will associate particular skills/resources/approaches etc with previous success without even realizing it. Also be wary of requirements intended to make sure that any successful tender will be easy to defend to upper management. Such requirements may seem like a good idea but they can exclude companies with better solutions from entering your vendor pool. If the tender is good you won’t have trouble defending its selection.

3. Don’t make writing the tender a job in its own right

Asking too much from a vendor in the tender process can make your tender less appealing. Asking a vender to supply an example financial statement with its tender is fine if you really need to ensure the long term financial stability of the vendor, but it penalizes and offends some smaller vendors unnecessarily. Asking for too much material as part of the tender itself can also be seen as a sink of non-income-generating-time for your vendors. A good litmus test is to not ask for anything you aren’t going to read fully. If you plan on just skimming something, then ask for the summary not a book.

4. Don’t discount LVV (low value vendors)

Small companies don’t necessarily mean lower quality. They can be small because they cater to a specialization or a particular niche. Take the time to separate your expectations of the project from your mental image of the perfect vendor. The same goes with new companies and start ups, they may have other ways to satisfy concerns over capacity and quality other than being the biggest or oldest company on the list.

5. Carefully review the IP requirements

Intellectual Property is a huge issue in IT project and the default position in most RFTs is that the client wants to own everything. While it sounds like the logical thing to ask, it’s often not necessary. Do you really need to own all the IP? Or do you simply need the full rights to use and modify it without attribution? Are you going to market the system or just use it in house? Does it need to be proprietary code or can some libraries/components be open source? Not insisting on total ownership when it’s not needed can drastically increase what a vendor can do within a budget. Take the time to look through the creative commons licensing definitions if you need inspiration.

Bottom line

If your project is small in budget or scale then you need to make sure that your RFT is small-vendor friendly. The demands you make of large vendors may be impractical on smaller projects and end up costing time and money you don’t have. However, if you take the time to be clear on what you really need and step away from your preconceptions you’ll find your vendor pool is fresher and more competitive. Just keep in mind that for the vender, getting a tender accepted should be the start of the hard work not the end of it.

Y a-t-il un pilote pour votre reporting ?

A lire sur:   http://www.decideo.fr/Y-a-t-il-un-pilote-pour-votre-reporting_a6118.html

Jean-Baptiste MEREL, Report One,  Vendredi 17 Mai 2013

Entre reporting et pilotage, l’équilibre n’est pas si simple à trouver pour les entreprises qui doivent rester réactives et performantes, quand on sait que près de 40 % d’entre elles ne survivront pas à leurs premières années. Si l’informatique décisionnelle apporte des réponses depuis plus de 20 ans, encore faut-il qu’elles soient suffisamment simples et efficaces pour ne pas devenir un frein à l’évolution de l’entreprise et à sa nécessaire agilité.

Jean Baptiste MEREL, Directeur de Marchés Report One.

12
inShare

Des indicateurs indispensables à l’entreprise

Depuis sa création, toute entreprise développe et fait vivre un système de reporting. Mais, au fur et à mesure qu’elle évolue et que le temps passe, le reporting devient vite trop lourd, trop coûteux, dépendant de spécialistes qui passent plus de temps à le créer qu’à le faire vivre. C’est un classique : combien de fois vous a-t-on répondu « si on veut modifier le tableau, ça va être compliqué ! » ou bien « ça va prendre du temps !!! » ? Et l’entrepreneur de penser : « mais où est le reporting du début, si simple et efficace, qui tenait sur une feuille A4 ? ».

Au-delà du reporting, l’entreprise développe aussi des tableaux de bord, indicateurs essentiels et proches du temps réel, visant à aider les cadres et décideurs à mieux piloter leurs activités en accord avec la stratégie. On parle alors de management visuel, de pilotage par les indicateurs…

Reporting et tableau de bord… Mais quelles différences ?

Pour imager ces deux notions, prenons l’image du conducteur automobile. Après un long trajet, il fait des pauses régulières et consulte son ordinateur de bord : sa consommation moyenne, le nombre de km parcourus… On peut l’assimiler au reporting.

Lorsqu’il est au volant, il peut également consulter en temps réel son tableau de bord composé d’indicateurs essentiels (vitesse, niveau de carburant, etc.) et peut éventuellement être alerté en cours de route. On retrouve ici le tableau de bord, instrument du pilotage.

Un dosage subtil à mesurer

Revenons à l’entreprise. Le patron d’une société de ventes de produits s’intéresse à son chiffre d’affaires (CA) par région : il fera du reporting. Le directeur commercial, lui aussi intéressé par le CA, mettra en place et communiquera un objectif de nombre de rendez-vous par semaine pour ses commerciaux, et suivra ce nombre quasi quotidiennement : grâce à son tableau de bord, il pilotera l’activité de son service.

Quand le premier arrêtera une situation pour analyser les périodes passées (année ou trimestre précédent), le second aura lui une vision temps réel de ce qu’il viendra de se passer.

Il faut prendre garde toutefois, à l’image du reporting, pour ne pas tomber dans les « stratégies de l’absurde » ! Dans son ouvrage, Maya Beauvallet[1] démontre par exemple, comment le manager d'une entreprise de fabrication de salami, qui voulait augmenter sa production, a mis en place un indicateur de pilotage pour compter le nombre de tranches produites par jour. Au bout de quelques temps, l’indicateur a bien augmenté… mais pas la production globale. Les tranches étaient tout simplement plus fines… !

Il faut dès lors se poser les bonnes questions :

- Comment puis-je réduire les processus inutiles tout en faisant face à la complexité grandissante de mon organisation ?

- Comment faire en sorte que chacun reste motivé et contribue à l’évolution de l’entreprise par l’analyse et la prise de décisions efficaces et adaptées à son environnement ?

Dans les faits, il n’existe donc pas de système parfait et universel

Que vous soyez un manager plutôt « reporting » ou plutôt « pilotage », il est essentiel de trouver le juste dosage entre ces deux pratiques complémentaires qui, si elles sont mal utilisées, peuvent se révéler à contre-emploi de leur objectif premier !

[1] « Les stratégies absurdes » - Maya Beauvallet – 2009 – Seuil Editeur

Five Steps Before Estimating Work

A lire sur:  Method123

Estimating is hard enough. It is even harder if you are not prepared. Estimating a 20 hour chunk of work is not so hard. Estimating for full projects or large chunks of work can be challenging. Templates can help, but consider the following steps before you begin the estimating process.

Get a clear picture of the work that is being estimated

Many problems with estimation come because the estimator is not really sure what the work entails. You should avoid estimating work that you do not understand. This should not imply that you can know every detail. The estimating contingency is a way to reflect some of this remaining uncertainty.

Determine who should be involved in the estimating process

The project manager may or may not know enough to make the estimates on his or her own. It is usually a good practice to look for estimating help from team members, clients, subject matter experts, etc. This will usually result in the estimates being far more accurate than you would get by yourself.

Determine if there are any estimating constraints

If there are estimating constraints, it is important to know them up-front. For instance, the end-date may be fixed (timeboxed). You should also know if the client expects Six-Sigma level quality in the deliverables, or if the 80/20 rule will apply. It is possible that there may be a fixed budget that cannot be increased. (This would be of interest so that you can reduce the scope of work, if necessary, to meet the fixed budget.) Knowing these constraints will help the estimators make valid assumptions regarding the cost, duration and quality balance.

Determine multiple estimating techniques to utilize if possible

There are a number of techniques that can be used to estimate work. If possible, try to use two or more techniques for the estimate. If the estimates from multiple techniques are close, you will have more confidence in your numbers. If the estimates are far apart, you need to review the numbers to see if you are using similar assumptions. In this case, you can also try to utilize a third (and fourth) estimating technique to see if one initial estimate can be validated and the other rejected.

Document all assumptions

You will never know all the details of a project. Therefore, it is important to document all the assumptions you are making along with the estimate.

The Customer May Not Know Enough to Completely Define the Project

A lire sur:  Tenstep

Sometimes the project manager places too high an expectation on the amount of foresight and vision that customers and sponsors have. In many cases, the project manager will go to the customer looking for answers to help define the project and the customer will not have all of the information needed. This happens all the time and it does not mean that the customer does not know what they are doing. In many cases, especially for large projects, the customer has a vision of what the end results will be, but cannot yet articulate this vision into concrete objectives, deliverables and scope. 

There are three approaches for when you don't know very much information on the nature of the project.

Increase Estimating Range Based on Uncertainty

Based on having less than complete information, the  project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining. On a normal project, for instance, you might estimate the work within +/- 10%. On a project with a lot of uncertainty, the estimating range might be +/- 50%. 

Break the Work into Smaller Projects

Another good alternative is simply to break the work down into a series of smaller projects based on what you know at the time. Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, in turn lead to the information needed for the final solution. You can define a project to cover as far as you can comfortably see today. Then define and plan subsequent projects to cover the remaining work as more details are known.  For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables. 

Uncover the Details as the Project Progresses

If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. In this third approach, you plan the short-term work in more detail, and leave the longer term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

This last approach uses an Agile philosophy. Agile projects are generally exploratory. The details of the project are uncovered as the project progresses. (There are many more differences in Agile projects, but this philosophy is one.) In a traditional project management model this would also be known as 'progressive elaboration' - which also means more details are uncovered as the project progresses.  

How to Store Your Project Files

A lire sur:  ProjectManager.com

Projects generate a lot of documentation, whether it is a business case, project requirements or status reports. It is sometimes difficult to know where to start when it comes to saving them securely. If you don't keep on top of your filing system, you will find it really difficult to locate your key documents when you need them. Here's how to make life easier.

Keep track of your project files with these simple tips.

Tip 1: Store your files online
Using an online project management tool or document repository is the best way to file your documents. Online storage means that you can access the files from wherever you happen to be in the world, whenever you want to. Create your own file storage folder within your project records, and use it to store all your documents, spreadsheets and presentations.

You can also store other types of files like document templates. If you record your meetings and presentations why not try storing audio and video files too?

Tip 2: Make them available to the team
Another great advantage of using online software to store your files is that you can make them available to the whole project team. Choose who you want to have access to your documents. You can easily give your team members permission to upload, read and edit documents in ProjectManager.com, which gives everyone the opportunity to collaborate on producing quality, useful, project documentation.

Tip 3: Keep your files together
It is hard to find an important document if some files are on a shared network drive, some in your online document repository, some on your laptop and some in your inbox. Where do you start looking for the right paperwork?

Keep all your files together by agreeing with the team that you will only use the online project management software to store your documents. That way, everyone knows exactly where to look.

Tip 4: Back up your files
Using online document storage also means that you have a secure back up of your files. Put a reminder in your calendar to back up your files regularly—just in case! Because documents are so important to projects, you need to have the confidence that you can recover anything critical if something happens to your laptop.

Tip 5: Track different versions
There is nothing more frustrating than working on a document only to find that someone else has made changes to it and you are not looking at the latest version. What a waste of time! Online document storage solutions give you the opportunity to automatically capture the version number of the document, and this means you can be sure that you are always looking at the latest copy.

Why programmers should study the art of programming

A lire sur:  http://www.techrepublic.com/blog/programming-and-development/why-programmers-should-study-the-art-of-programming/4160

By Chip Camden,  May 10, 2013, 8:58 PM PDT

Takeaway: Chip Camden encourages programmers to cultivate a broad and deep understanding of the trade by accumulating a knowledge of its history and keeping an eye on recent developments.

To the average programmer in the trenches, debating the theory of computation is like discussing the chemical properties of saltpeter while in a gunfight: it may all be correct, but it doesn’t apply directly to the problem in front of them. Why waste time imagining the outcome of a deathmatch between Haskell Curry and Alan Kay when we’ve got a deadline to slap a new web UI over our legacy application? Why should we care whether we’re using a monad or an exception to return an error state? What the heck does “orthogonal” mean? Don’t give me a research paper, just give me code that works. And so runs the “get it done yesterday” logic.
From many a project manager’s point of view, programmers who dabble in computing theory pose an even greater danger than wasting time: they threaten to poison the project with new ways of doing things. This attitude is not entirely unjustified. Every new idea that promises to revolutionize software development seems to do quite a bit of damage to the industry before the hype wears off and it finds its proper place within the programmer’s arsenal of available tools. Converts to these theories try to squeeze every problem into the new mold whether it fits or not. Just as an appalling misapplication of the Theory of Evolution provided a justification for Nazi genocide, so has the misapplication of Object Orientation, for example, led to all manner of programming ugliness in the name of purism (may Godwin have mercy on my soul).
The history of programming is dotted by false starts and pendulum swings. I remember in the wake of Dijkstra’s famous Go To Statement Considered Harmful, myriads of programmers created all sorts of grotesque code contortions in order to avoid using a GOTO, even where one was badly needed. The slavish obedience to this and other rules of Structured Programming became so detrimental that once when the objection “It isn’t structured” was raised to an idea before the ANSI subcomittee on which I served, I replied “I don’t believe in Structured Programming.” The silent shock on every face made me expect to be instantly removed from membership. I might have, too, if my friend and mentor Ken Lidster hadn’t spoken up and explained that what I meant was that I objected to a legalistic interpretation of Structured Programming principles. He was right, though at the time I felt that he had watered down my bold assertion.
Nevertheless, the pursuit of programming theory does do us some good. If it weren’t for all the brainpower that’s been applied towards improving the practice of software development, we’d all be punching machine instructions on paper tape or Visual Basic on Windows. Thank goodness someone said, “There has to be a better way!” Thank goodness someone keeps on saying it.
Programming language developers aren’t the only ones whose work improves under this consideration. Despite the risk of fanaticism, journeyman programmers can also enhance their contributions (and hopefully, their careers as well) by exercising their skills in areas that lie beyond their strictly defined responsibilities. Especially where it lies just beyond their horizon, the question “How can we improve software development as a discipline?” may yield a significant payoff. The danger lies in half-learning and poor self-evaluation. As Alexander Pope famously said in his Essay on Criticism:

A little learning is a dangerous thing;
Drink deep, or taste not the Pierian spring.

The professional programmer should drink deeply. By cultivating a broad and deep understanding of our trade, accumulating a knowledge of its history, and keeping an eye on recent developments, he or she will develop the wisdom to distinguish hype from substance and to apply each tool to the purpose for which it is best suited.
Note: This post originally published on April 24, 2011.

Avis d’expert : Réussir la présentation de votre business plan grâce au Storytelling (partie 2) : les questions-clés

A lire sur:  http://entrepreneur.lesechos.fr/entreprise/creation/actualites/avis-d-expert-reussir-la-presentation-de-votre-business-plan-grace-au-storytelling-partie-2-les-questions-cles-10028881.php

13 mai 2013 |

Créateurs, repreneurs, chef d’entreprise, le business plan est Le document phare qui présente à tous vos interlocuteurs votre projet. Comment réussir son élaboration via un storytelling maîtrisé ? Le point avec un expert, Jean-Christophe Pic, expert en Business Plan et en Gestion Financière *

Sur le même sujet

Avis d'expert : Réussir la présentation de votre business plan grâce au Storytelling (partie 1)

La pratique du storytelling, vous guidera pour construire avec efficacité votre business plan, car il s’agit de présenter une histoire autour de votre projet, une histoire qui se construira autour des interrogations suivantes :

-    Quelle est votre vision, où vous projetez-vous ? Pourquoi souhaitez-vous arriver là ? Quelles sont vos motivations et valeurs qui vont vous faire réussir ? En quoi avez-vous ressenti quelque chose de plus que les autres ? Pourquoi serez-vous la bonne personne pour le mener à bien ? 

-    Qui êtes-vous, quelle communauté d’intérêt avez-vous su créer autour de votre projet ? Quelle est votre expérience, votre histoire personnelle autour du projet ? En quoi, en cas de difficultés, votre équipe sera la mieux à même d'affronter l’adversité ?

-    Qu’apportez-vous ? un nouveau produit, service, un concept ? En quoi la vie sera meilleure une fois votre idée réalisée ?  L’enjeu est ici de montrer l’histoire de votre idée, comment elle vous est arrivée et en quoi elle s’inscrit dans le sens de l’Histoire

-    Quelles sont les solutions déjà existantes ? Quels sont les concurrents ? Expliquez en quoi ils ont ouvert la voie et ont donné l’envie aux consommateurs/utilisateurs

-    Pour qui les produits, services, concepts que vous proposez auront-ils de l’intérêt ? Quels sont vos marchés ? Quelles sont les attentes de vos consommateurs/utilisateurs ? Sont-ils nombreux ? Peu nombreux ? Sont-ils prêt à le payer cher ? A l’acheter plusieurs fois ou à le prescrire fortement ? Montrez les ordres de grandeur : taille, prix, niveau de renouvellement, capacité de fidélité.

-    Comment allez-vous vous faire connaitre du client ? Quelle histoire allez-vous lui présenter sur votre offre ? Avez-vous déjà des clients, quelle est votre histoire avec eux ? Quelles sont les histoires de vos concurrents, que vous apprennent-elles, comment se mettent-ils en valeur ? Montrer que vous avez compris les enjeux et appris de vos concurrents proches ou lointains.

-    Quels sont vos enjeux financiers ? Quels sont vos besoins financiers ? Comment allez-vous utiliser cet argent ? Toute action nécessite des ressources, n’ayez pas peur de les mentionner, cela montre votre crédibilité dans votre analyse, et fait adhérer vos interlocuteurs à la qualité du travail effectué dans la réflexion préparatoire à l’action.

-    Pourquoi est-ce le moment de vous lancer ? Y a-t-il une opportunité ?  Les circonstances s’y prêtent-elles ? Les moyens sont-ils présents et en attente ? Vos produits ou services sont-ils réclamés ? Montrer que votre intuition, expérience, réflexion vous amène à des conclusions qui confirment ce que vous affirmez.

Conseil :

Dès le début de votre présentation, intégrez un « executive summary », ou « résumé exécutif » qui synthétisera tous ces éléments, et qui montrera pourquoi vous allez réussir et que c’est une belle histoire, celle que vous allez expliquer à votre auditoire. Présentez les chiffres clés, les principaux membres de votre équipe, les demandes que vous allez satisfaire, et aussi les risques que vous allez affronter ! Montrez de quoi vous avez besoin pour lancer ou continuer l’histoire avec succès.

Pour aller plus loin : retrouvez prochainement l’art et la manière de booster votre business-plan grâce au storytelling, partie 3, avec les conseils de Jean-Christophe Pic.

*www.jeanchristophepic.com

Jean-Christophe Pic, expert en Business Plan et en Gestion Financière *