Five Project Management Mistakes

A lire sur:  Method123

Now, let’s say you have done a good job defining and planning the project. You’re home free, right? Not exactly. It is very common that once the project starts, the sponsor ends up asking for more (or different) work than what was originally agreed to. This is the time you must invoke scope change management. If you don’t, you will end up trying to complete more work than what was originally agreed to and budgeted for. In other words, you are heading down the road to trouble.

Five Project Management Mistakes

Mistake #2: Poor scope management practices

Managing scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible. The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries and deliverables of your project. The business requirements are gathered to provide more detail on the characteristics of the deliverables.

Defining scope means that you have defined the project boundaries and deliverables, and the product requirements. These should all be approved by your sponsor.  

The project manager and project team must realize that there is nothing wrong with changing scope - as long as the change is managed. If you cannot accommodate change, the final solution may be less valuable than it should be, or it may, in fact, be unusable.

Every project should have a process in place to manage change effectively. The process should include identifying the change, determining the business value of the change, determining the impact on the project and then taking the resulting information to the project sponsor for their evaluation. The sponsor can determine if the change should be included. If it is included, then the sponsor should also understand the impact on the project, and allocate the additional budget and time needed to include the change.

The most common problems with scope change management are:
 

• Not having the baseline scope approved, which makes it difficult to apply scope change management.
• Not managing small scope changes leaving yourself open to "scope creep".
• Not documenting all changes - even small ones.
• Having the project manager make scope change decisions instead of the sponsor (or designee).

If you find that your project is starting to trend over its budget and schedule, try to find the cause. In many cases you will find that you are simply taking on more work than you originally agreed to. If you do not have a good scope change process in place, it is never too late to start.

10 of the biggest IT sand traps

A lire sur:  http://www.techrepublic.com/blog/10things/10-of-the-biggest-it-sand-traps/3639

By Mary Shacklett

March 21, 2013, 2:27 PM PDT

Takeaway: Many of the issues plaguing IT departments can be mitigated or sidestepped altogether. Here are some ways to deal with several common pitfalls.

IT faces challenges on a daily basis. But most experienced IT’ers have learned to avoid the worst sand traps so they can prevent time and energy drains. What are today’s biggest IT sand traps — and what best practices can you use to circumvent them?

1: Uncooperative users

Uncooperative users are still out there, as they have been through the years. Most don’t cooperate out of fear of a new application — or because of a comfort level with a present application that they don’t want to give up. It is important for IT to remember that when it changes an application, it also changes a person’s daily workflow. This can be disconcerting, even for younger users. The key is to engage users in application dialogues at the very beginning. Involve them in early app design and prototyping so they already know and buy into how the app is going to work before it is ever plugged into production.

2: Unhelpful users

Unhelpful users are trickier to work with because they frequently come in the guise of “helpful” individuals who cross a threshold when they become too helpful. They offer reams of tweak suggestions for apps and never want to accept an app as being complete for a given release. Enhancement creep of this nature introduces risk into IT project deadlines. The best way to deal with it is to establish firm cutoffs for app development and enhancement cycles that everyone agrees to.

3: Lack of tool integration

Everyone talks about cloud, mobile computing, and the blurring of lines between computing platforms. But vendors of infrastructure software don’t necessarily make managing across a diverse environment easier. Each vendor wants you to use its own toolset for management, and it isn’t always clear which tools are subordinate to other software infrastructure management tools.  Consequently, it becomes difficult to fit everything into an “uber” infrastructure solution where you really can see everything through a single pane of glass. The best thing for IT to do is to require prospective tool vendors to show what application programming interfaces (APIs) they have that work with other management software. The APIs can be tested with other software in a proof of concept (POC) before buying. Finally, avoid the use of homegrown tools that don’t readily interface with anything on the market.

4: Platform loyalty

IT’s strength is its technical know-how. This know-how is accumulated over the years and becomes a career calling card for most IT professionals. Unsurprisingly, the sledding can get rough when someone who has worked on say, UNIX, for 20 or 30 years, is told to move to a Linux environment.
One way to ease the transition (if it is necessary) is to introduce these individuals to the new platform and provide the training and support they need for the crossover. If they’re adamantly opposed to the change, there might be an opportunity for them to move into a maintenance role for systems that will continue to run on the old platform. If you can’t provide that role, as a last resort you might have to encourage them to seek employment elsewhere — in a shop that continues to use the platform they want to work on. In all cases, it is best to address these platform loyalty cases immediately and upfront, before resentment (and even lack of cooperation in projects) begins to set in.

5: Poor project management

Despite new project management techniques and tools, project management remains a weak area in IT. There are several reasons for it: a failure to cross-communicate across the project; the failure of project managers to “walk around” and really check out first-hand the status of work (besides just seeing the updates on a project tracking chart); and a breakdown of communications between the IT and the end user sides of the project team.
The best way to ensure great results in projects is to make projects smaller (and therefore more manageable), to encourage (and enforce) open communications, and to use collaborative project management tools that are now available in the market. It is equally important to perform post mortems of all project work — to learn what went right and what could have been done better on each project — and to take that knowledge into future projects.

6: Lack of documentation

Documentation isn’t stressed in IT, which makes it a weak link in most IT work. No wonder most IT departments report that upward of 50 percent of their time is consumed in app maintenance. Less time would be spent in maintenance if documentation of what the original app was doing (along with history of maintenance already performed) had been done. Two ways to combat this are the adoption of new app development software that automatically documents work and a build-in of project time for app documentation and QA of the doc.

7: Poor data quality

The best technology in the world isn’t going to change duplicate customer records with misspelled addresses or incomplete phone numbers. For data already on record, data deduplication can be used to ferret out duplicate records before they are stored or archived to disk. For new data, better field edits in applications can improve the quality of data that is being entered into data repositories.

8: Jargon

IT (like other technical disciplines) can become so comfortable using acronyms and jargon that it doesn’t realize that it is using these terms with business users who might not understand them. This can generate communications breakdowns or even intimidation in relationships. IT can avoid this by stressing (and if necessary, training) IT staffers who work with end users to avoid these specialized terms and to stick with plain English.

9: Unrealistic deadlines

The pace of business is relentless and quick. As usual, IT gets pushed into accepting project deadlines that are too aggressive for the work that needs to be done. When this happens, IT delivers incomplete projects that are missing key pieces that subsequent enhancement cycles must handle. This is okay if the business is in total agreement with the approach. (In fact, it has worked very well in some areas, such as marketing.) However, if there is a governance/security issue, or if the app is required to be both complete and thoroughly tested, it is IT’s responsibility to tell business management what the effort will take, how long it will take, and what the risks are if the effort is not undertaken.

10: Lack of people skills

IT continues to come up short in soft skill areas. CIOs should recognize this by budgeting for and providing people skills training to key IT contributors — and they should up the ante by soliciting feedback from end users on the quality of IT interpersonal communications.

Other sand traps?

What issues have been a problem for you during your IT career? Share your experiences and advice with other TechRepublic members.

The 12 habits of highly collaborative organizations

A lire sur:  http://www.techrepublic.com/blog/tech-manager/the-12-habits-of-highly-collaborative-organizations/8197

By Guest Contributor

March 18, 2013, 6:12 AM PDT

Takeaway: Here are twelve collaboration patterns or “principles” that successful organizations follow.

Did you know that there are more possible moves in a game of chess then there are atoms in the entire universe and seconds that have elapsed since the big bang?  In fact, chess can be a virtually endless game.  If that’s the case then how do chess masters emerge?  What’s the point of trying to study something if the moves are endless?  Any good chess player will tell you that one of the keys to success is the ability to recognize patterns and situations to help you identify what the best next move is.
When looking at collaboration and the future of work, the same logic applies.  Every company is unique and no two collaboration initiatives are the same.  However, after working with, speaking with and researching hundreds of companies (such as Wells Fargo, Unisys, Lowe’s, IBM, EA, The U.S. Government, TELUS, Intuit, Shell, and many others) my team at Chess Media Group and I have identified twelve collaboration patterns or “principles” that the successful organizations follow.  Below you will find a visual highlighting these principles followed by a more in-depth description of each one.

1.  Individual benefit is just as important as the overall corporate benefit (if not more important)
Don’t focus on the overall corporate value and benefit when communicating collaboration to employees.  Employees care about how this will impact them on an individual basis.  How will this make their jobs and lives easier?
2.  Strategy before technology
Before rushing to pick that shiny new collaboration platform focus on developing a strategy which will help you understand the “why” before the “how.”  This is crucial for the success of any collaboration initiative.  You don’t want to be in a position where you have deployed a technology without understanding why.  This can become a very costly mistake later.
3.  Listen to the voice of the employee
We are always so adamant about listening to the voice of the customer, what about the voice of the employee?  When going down the collaboration road within your enterprise it’s important to make employees a part of the decision making process from step one.  Listen to their ideas, their needs, and their suggestions and integrate their feedback in your technology and strategy.
4.  Learn to get out of the way
This is something Andrew McAfee (author of Enterprise 2.0 and co-author of Race Against the Machine) talks about quite frequently.  Learn to empower and support your employees and then get out of their way.  By trying to enforce and police everything you stifle collaboration within your organization.  Some best practices and guidelines are fine to have but let your employees do what they need to do.  Managers need to learn to follow from the front.
5.  Lead by example
If leaders at your organization don’t use and support collaborative tools and strategies then why should the employees?  Leaders are very powerful instruments to facilitate change and encourage desired behaviors. They must be visibly on board and this goes beyond just funding.
6.  Integrate into the flow of work
Collaboration should never be seen as an additional task or requirement for employees.  Instead collaboration should fit naturally into their flow of work.  For example instead of having employees use multiple usernames, passwords, and log-in sites; create a “front-door” to the enterprise accessed through your collaboration platform.
7.  Create a supportive environment
If your organization focuses on rewarding employees for individual performance as the main driver of success then it will become quite hard to encourage employees to share and communicate with each other.  Why would they want to?  We this quite often in financial services firms who promote employees to managerial roles such as VPs (and higher) simply because they brought in a lot of money.  There is nothing wrong with rewarding employees for great performance but it’s also crucial to reward and recognize teamwork and collaboration.  For example organizations can make a percentage of an employee’s bonus tied to how well they collaborate with their co-workers (some large enterprises are starting to experiment with this).  A supportive environment also means having training and education resources available for employees as well as evangelists within the organization.
8.  Measure what matters
There are a lot of things that an organization can measure but that doesn’t mean that all of these things should be measured.  Focus on the metrics that matter to your organization and the ones that are tied back to a business case.  Some organizations focus on “busy” metrics such as comments submitted or groups created.  Others focus on metrics such as engagement (defined as how connected and passionate an employee feels about the company and the work they do).
9.  Persistence
I believe that collaborative initiatives shouldn’t be pilots they should be corporate initiatives.  These efforts can certainly take time but if the organization makes the decision that collaboration is the direction they want to go down then that’s it.  No giving up and no turning back.  Moving forward, organizations cannot succeed without connecting their employees and their information.  Making collaboration work isn’t an option it’s THE option.
10. Adapt and evolve
It’s important to remember that collaboration is perpetual.  It’s a never ending evolution as new tools and strategies for the workplace continue to emerge.  This means that it’s important for your organization to be able to adapt and evolve as things change.  Keep a pulse on what’s going on in the industry and inside of your organization.  This will allow you to innovate and anticipate.
11. Employee collaboration also benefits the customer
While customer collaboration and employee collaboration do solve very different and unique problems, employee collaboration has tremendous value to your customers.  Employees are able to provide a better experience and superior support by being able to tap into internal experts, information, and resources which can be used to help customers.  Consider a customer that is working with a support representative who unfortunately does not know how to solve the customer’s problem.  The employee however has access to the entire organization to find the right information and share it with the customer.
12. Collaboration can make the world a better place
Perhaps the most important principle of collaboration is that it can make the world a better place.  Sure, collaboration can make our employee more productive and benefit our customers.  But collaboration also allows employees to feel more connected to their jobs and co-workers, reduces stress at the workplace, makes their jobs easier, allows for more work freedom, and in general makes them happier people.  This means less stress at home, less arguments with spouses, and more time to spend with loved ones.  Collaboration not only positively impacts the lives of employees at work but also at home.

Five Project Management Mistakes

A lire sur:  Method123

The following series of five emails describes the five most common project management mistakes.

Have you ever attended an end-of-project meeting on a project that had major problems? If you have, chances are that one of the major themes you will hear is that “we should have spent more time planning.”

Five Project Management Mistakes

#1: Inadequate Planning

I have heard project managers say that the time they spend planning could be better spent actually "doing the work". This is not right. Before the project work begins, the project manager must make sure that the work is properly understood and agreed to by the project sponsor and key stakeholders. The larger the project, the more important it is that this information be defined formally and explicitly. When you think about it, many project problems can be traced to problems in planning. These include

• Poor estimates based on not understanding the totality of the work.
• Lack of scope change management because scope was not properly defined to begin with.
• Issues occurring because of poor risk management.
• Missing work because the schedule is not thought out.
• Not understanding all the stakeholders involved.

It should not be surprising, then, that the best way to avoid this problem is to do a good job of planning the project up-front. There are four main components to the planning process.

• Defining the work. You need to understand the nature of the project including objectives, scope, assumptions, risks, budget, timeline, organization and overall approach.
• Understanding the schedule. You should create a  project schedule before the project starts. This is needed to help you determine how to complete the work, and to estimate the total project effort and duration.
• Estimating costs. You and the sponsor need a good estimate of costs before the project gets going.  
• Agree on project management processes. This will include how the project manager will manage scope, issues, risks, communication, schedule, etc.

People ask me how much time it takes to complete the project planning. The answer is "sufficient". You need to spend the time to define the work, create a schedule, estimate the costs and set up the project management processes. If your project is small, this should not take much time. If your project is large the planning may take a log time. In other words, planning is scalable based on the size of the project.

Spending time on good planning ends up taking much less time and effort than having to correct the problems while the project is underway. We all know this to be the case. We just need to practice this on our projects.

Is configuration management your IT project's missing link?

A lire sur:  http://www.techrepublic.com/blog/project-management/is-configuration-management-your-it-projects-missing-link/5727

By Eddie R. Williams

March 14, 2013, 9:01 AM PDT

Takeaway: Eddie R. Williams lists 10 steps for establishing the configuration management your IT project needs.

Your IT project will soon be in trouble if you fail to establish configuration management (CM) as early as possible during the systems/software development life cycle (SDLC). This is true regardless of whether you use a traditional software development methodology/process such as “Waterfall” or an Agile, iterative methodology. Ideally, you should start thinking about CM before or during the proposal activity. An effective configuration control library provides control over documentation, source code, etc. and streamlines the build/release process. Finally, you must also ensure the use of best practices for program/project management, development, quality assurance (QA), and so on.

Why is CM so essential?

CM is a process for establishing and maintaining consistency of a product’s performance, functional and physical attributes with its requirements, and design and operational information throughout its life. (MIL-HDBK-61A, Military Handbook: Configuration Management Guidance, Department of Defense. 07-February-2001 and ANSI/EIA-649B, National Consensus Standard for Configuration Management, TechAmerica. 01-April-2011.)
Effective CM is essential to ensure customer/user satisfaction and develop a quality product. Without CM, it is almost impossible to control the documentation, source code, and other data that describe your system and are used throughout the SDLC.

The 10 steps to ensure successful CM

Create your CM plan during the conceptual demonstration and validation phase, which the Rational Unified Process (RUP) refers to as Inception and Elaboration.
1. At contract award, identify the configuration items (CIs) based on the following criteria:

• System allocation (major functions or capability of the system)
• Application functionality or capability
• Data and information requirements
• Each processor
• Criticality/safety
• Size (source code lines)
• Cost and schedule
• Quality (reliability, reusability, maintainability, testability, modularity, etc.)
• Logistics support
• Maintenance

Note: CIs are also called Computer Software Configuration Items (CSCIs) for software systems development.  The configuration identification process was originally defined in MIL-STD-973, 483, and DOD-STD-480A.
2. Determine the appropriate development methodology for the system or product (if not yet decided).
3. Specify the required documentation for each product (CI/CSCI) based on the contract requirements, standards, and specifications. Note: A waterfall project may have extensive specification documents. For Agile, brief but well-defined user stories with limited text and diagrams and tasks for each iteration are often preferred.
4. Set up the configuration control library. It does the following:

• Provides control of master files and documentation (on-line and offline), such as specifications, related documentation, computer programs, software, databases, etc.
• Supports the build and release processes and activities.

5. Set up a change management process that includes configuration control and a secondary process to expedite critical or time-sensitive changes.
6. Issue numbers and identifiers to each product (CI/CSCI), its components, and related documentation. Important: It really helps to establish consistent naming and labeling conventions for requirement and design documentation, interfaces, code listings, and so on.
7. Determine and prioritize the planned component or functional releases (deliverables), based on the requirements and the architecture.
8. Establish the configuration baselines. Configuration baselines are points in time for management, control, and release purposes.
9. Set up QA, validation and verification (V&V), and/or test validation processes that complement your CM method.
10. Throughout your program or project, do the following:

• Continue to implement and carry out your CM activities
• Evaluate your success (lessons learned), and
• Correct as necessary.

Branding Your Project

A lire sur: Tenstep

At TenStep, we define three major categories of communication within a Communications Plan – mandatory, informational and marketing. If your project is controversial or if it requires culture change to be successful, you should focus on marketing communications. 

Branding is a more sophisticated form of marketing communication. The purpose of branding a project is to associate an emotion or a feeling with your project. This is exactly what marketing people try to do when they brand a product. For instance, The Coca-Cola Company hopes that you feel good about its products and that you will choose its products from a crowded store shelf because you like the image and emotion associated with it. Maybe it works. 

The purpose of branding a project is to associate a positive image and emotion with your work. This is not something most projects need to be concerned about. However, ask yourself some questions regarding the impact your project will have on the organization.

• Does it impact a large number of people or maybe the entire company?
• Will it require a culture change or a change in the way people do their job?
• Will your project make people nervous or afraid? For instance, will it result in efficiencies so that less people are required to do the same function?

These are the types of projects that would be candidates for branding.

All large projects get branded. If you don’t do anything, this branding is generally negative. It is just the nature of people that they seem to think that change is bad. Positive branding communication helps you proactively build the image you want to portray rather than getting stuck with one.

When considering a branding strategy, ask whether it is important for people to have a positive feeling about your project. For example, when people hear of your project, do you want them to think of the benefits your project is bringing or do you want them to think about how bad the project is? Should they think of the company responding to competitive challenges or should they be wondering if the project will cost them their job? Do you want them to have positive thoughts or negative ones?

There are activities that a project can perform to help with the branding campaign.  Examples of activities include establishing a positive project name, distributing banded materials, publicizing project successes, etc.

Why the fuss?

You might be wondering why this all matters. Does this sound like just a bunch of fluff and unnecessary work? It is not. It matters because it is much more difficult for your project to be successful if the people that have to change are negative. It is much easier for you if they are positive about the change - or at least neutral. That is where the value-add comes in.

How to Encourage Your Team to do Timesheets

A lire sur:  ProjectManager.com
 

If you'd like to know what your team are working on and how long tasks are taking, then ask your team to fill in basic timesheets.

Unfortunately, if you mention "timesheets" to team members they will often groan! So learn these 5 steps on...

How to Encourage Your Team to do Timesheets

Make it easy for your team to record their time with these 5 simple steps.

Step 1: Explain why you are collecting data
People are more likely to complete their timesheets if they know what you are doing with the information. Explain how it helps you manage the project more effectively. You can tell them that it provides really useful information to validate the estimates and it ensures that everyone is working on the right things at the right times. You can adapt the project schedule depending on how quickly tasks are being done.

Step 2: Make it easy
One of the reasons why people don't complete timesheets is because they are difficult to fill in. They don't have to be. Choose an online project management tool that allows everyone on the team to complete their timesheet information with a few clicks. Look for one that has a 'copy previous week' button like the one in this Time Tracking Software to save even more time.

Step 3: Link the data to the project plan
Ideally your timesheet data should link automatically to the project plan so team members don't have to complete two sets of information. They will feel as if the software is actually helping them to do their job instead of asking them to fill in lots of forms for seemingly no purpose.

Step 4: Share the reports
Time tracking reports allow you to see if your project is running on time or if you are behind schedule. These can be really useful tools to help you manage the project successfully. You can also see how much time has been spent on the project to date. Showing the reports to your team members can help reinforce the message that their timesheet data is very valuable and that it is worth completing the timesheets.

Review the reports before you share them with the team as you don't want confidential information to be available publicly. That shouldn't be a problem for most projects but it is worth checking before you send the information to everyone.

Step 5: Review your estimates
Finally, use your timesheet information to review your estimates on the project. If a task is taking longer than expected, this is a great time to change your project schedule as appropriate. Use the historical data from timesheets to better predict the future. After all, if a task took longer than expected, chances are that your estimate was a bit optimistic and you'll need to review it for next time.

Start Your Project with a Kickoff Meeting

A lire sur: tenstep

Just as a project should have a formal end-of-project meeting to signify that it is complete, you should also hold a formal kickoff meeting to start a project.

The purpose of the kickoff meeting is to formally notify all stakeholders that the project has begun and make sure everyone has a common understanding of the project and his role. Like all formal meetings, there should be an agenda. There are a number of specific things you want to cover at this meeting:

• Introduce the people at the meeting.
• Recap the information in the Project Charter, including the purpose of the project, scope, major deliverables, risks, assumptions, etc.
• Discuss the important roles and responsibilities of the project team, clients and stakeholders. If there is confusion about the role of any person or organization, it should be discussed and clarified now.
• Go over the general approach and timeline of the project. This gives people a sense for how the project will unfold. In particular, you will want to ensure that people understand what they need to be doing in the short-term to support the project.
• Answer any outstanding questions. The purpose of the discussion is not to rehash the purpose of the project, but to allow people to voice specific questions or concerns they have as the project begins.
• Confirm that the project is now underway. If the project has not started yet, it should now be ready to start immediately.

In general, the project team, sponsor and major stakeholders should be in attendance. If this results in too many people for comfort, you can consider having only the major players attend. You can then meet with others in subsequent mini-kickoff meetings or you can send the relevant meeting information to the people who could not attend.

Although most kickoff meetings can be conducted in an hour or two, others might require a day or two. The longer kickoff meetings are especially important if the project is very complex or controversial.

It is said you never have a second chance to make a good first impression. This is true with the kickoff meeting. You are using the meeting to help set expectations for the project. If the meeting is unorganized, chaotic or a waste of time, the participants will probably carry those perceptions into the project as well. The project manager needs to make sure that he has prepared well for this meeting and that it goes smoothly.

N°167: Gérer les approvisionnements

A lire sur:  tenstep

 

Parfois, il est plus sensé de fabriquer un produit à l’interne et d’autres fois, il est plus judicieux d’acheter le produit. Toutefois, à plusieurs occasions, on peut avoir le choix d'acheter ou de fabriquer un produit. Dans ce cas, une analyse plus approfondie est nécessaire afin de déterminer s'il est préférable de fabriquer ou d'acheter.

Le processus suivant peut être utilisé pour sélectionner un fournisseur de services ou pour acheter un produit. Le processus n'est pas ajusté selon la taille du projet. Le même processus de base fonctionne pour tous les projets. La diligence et l'effort consacrés à chaque activité sont en fonction de la taille et de l'implication de la sélection des fournisseurs. Si les conséquences de la sélection sont mineures, vous pouvez réduire la diligence que vous consacrez à chaque activité. Si l'impact sur le projet est important, vous devrez faire preuve de plus de rigueur et de diligence dans les activités.

Planifier les approvisionnements

Pour toutes les organisations, il y a des moments où elles doivent chercher des fournisseurs afin de pourvoir à certains besoins. Le processus est simple, mais le traitement de certaines fournitures peut prendre beaucoup de temps. Les techniques décrites ci-dessous peuvent être utilisées dans presque tous les processus de sélection, qu’il s’agisse de choisir un logiciel, un fournisseur, des équipements informatiques, etc. Le processus est décrit ici à un niveau très général et a besoin d’être élaboré avec les détails appropriés dans le cadre de votre projet.

Recueillir et classer les besoins commerciaux

Il est très difficile de sélectionner un fournisseur si vous ne savez pas exactement quels sont vos besoins ; aussi la première partie d’un projet consiste-t-elle à rassembler les exigences commerciales. Cela ressemble au processus de collecte des exigences commerciales d’un projet ordinaire. Il faut se poser des questions telles que :

·         En quoi ce fournisseur nous sera-t-il utile?

·         Quel problème sera résolu en travaillant avec lui ?

·         Quelles compétences doit-il posséder?

Assez souvent, vous ne pourrez pas identifier toutes les exigences en interrogeant les clients. Il se peut que les clients ne soient pas assez informés pour connaître les exigences de façon complète et correcte à 100%. Dans un projet normal, il vous suffira d’ajouter le reste des exigences en utilisant le processus de modification du contenu. Mais quand il s’agit d’un projet de sélection de fournisseur(s), il faut tout faire pour arriver à recueillir les exigences correctes le concernant, autant que possible dès la première fois. La découverte d’exigences manquantes, après avoir effectué la sélection du fournisseur, pourrait fort probablement se faire trop tard.

Chaque exigence devrait être évaluée à l’aide d’une échelle numérique, ou en utilisant les qualificatifs grande/moyenne/faible, ce qui permet de refléter son importance relative par rapport aux autres (vous pourriez aussi utiliser d’autres échelles, bien sûr). Votre commanditaire et vos parties prenantes devront aussi examiner et approuver cette liste exhaustive d'exigences relatives aux fournisseurs et la méthode de pondération utilisée.

En plus des exigences commerciales, d'autres caractéristiques pourraient vous intéresser chez le fournisseur :

·         Ensemble des coûts ou le coût du cycle de vie

·         Capacité technique

·         Management et approche du management de projet

·         Approche technique

·         Capacité financière

·         Capacité de production et intérêt

·         Taille et type de l'entreprise

·         Références

·         Droits de propriété intellectuelle

·         Droits de propriété

·         Plus

Terminologie de management de projet

Outil. Elément tangible, tel qu'un modèle ou un logiciel, utilisé lors de l'exécution d'une activité pour générer un produit ou un résultat.

Organisation fonctionnelle. Organisation hiérarchique dans laquelle chaque employé est sous l'autorité d'un seul supérieur hiérarchique, et le personnel est groupée par domaine de spécialisation et dirigé par une personne dotée d'expertise dans ce domaine.

Abréviations courantes

PMIS (anglais) : Project Management Information System

          (français) : Système de gestion de l'information du projet

4 Tips for Project Communication

A lire sur:  Method123

If you're working on projects, then read on to learn these...

Back in the 60', Motown's "I Heard it Through the Grapevine" was a huge hit, made famous by Marvin Gaye's recording. Even though he himself is no longer with us, the grapevine he sang about is alive and well, as it's a timeless metaphor for the way news travels.

In a project environment, the circulation of unofficial information and rumors is enough to make heads spin. We set up official communication plans that detail who knows what and when, but struggle with managing the unofficial information. The following are tips to stop the confusion and manage the grapevine effectively:

Tip 1 - Become Part of the Grapevine
People love talking about what goes on within their work environment. The grapevine truly does exist in all companies. Assume the projects you manage are one part of that conversation, insert yourself into it and ask people what they are hearing about your projects. Is there any news from above? Are resources happy? Then, be sure to add your own facts into the mix. A little bit of accurate information never hurt anyone.

Tip 2 - Combat Negative Messages with Facts
Negative communication sometimes gets spun into a mile-long email thread. Inaccurate information and intensity of emotion continue to escalate the longer the email thread grows. The best antidote to negative communication is to get the facts out there as quickly as possible. Compose a thoughtful and precise "Reply All" with a handful of relevant facts to get everyone in sync. Then, kill the thread and take it offline.

Tip 3 - Stop the Bad Press
Most talk on the grapevine is harmless, primarily serving as an interesting diversion during a long day at work. People don't really pay that much attention to it. However, innocuous gossip can turn into hurtful and malicious slander. You need to track down the source of that information immediately and make it stop. Find out why someone feels compelled to put forth such negative propaganda about your project and deal with it face-to-face.

Tip 4 - Fill the Vacuum
You may have projects that aren't impacted by negative communication. However, you are left with a vacuum of communication. It's up to you to fill this void with positive and factual information about your project. Send out pertinent emails, give appropriate updates at company meetings, and have one-off conversations. That way, people will really have something to talk about when your project gets tangled up in the grapevine.

The grapevine has been around since the time the 3rd person walked on this Earth. There's nothing you can do to stop it from happening, so include it as part of your unofficial communication plan. You'll notice a big difference with the buzz on your projects.

DevOps : rencontre avec un early adopter

A lire sur:  http://cloud-experience.fr/devops-rencontre-avec-un-early-adopter-2.html#more-3192
 

Par jean marc defaut le 11 mars 2013

Comment accélérer et sécuriser la mise en production de vos applications? Depuis quelques mois maintenant le sujet DevOps fait partie prenante des débats autour du Cloud Privé. Pour la Société Générale, le stade des réflexions est dépassé depuis plus de deux ans et la mise en pratique des concepts de « Continuous Delivery » est dorénavant une réalité.

Mon habit d’évangéliste a cela d’excitant qu’il me donne l’occasion de débattre de la pertinence des différentes approches du Cloud appliquées au monde de l’entreprise. En contrepartie, il me faut naturellement faire face à une certaine dose de scepticisme. Parfois cependant, au détour d’un rendez-vous, j’ai la surprise et le plaisir de découvrir un véritable pionnier. Quelqu’un qui, de son côté, a suivi le même cheminement et est arrivé aux mêmes conclusions. Cette expérience enthousiasmante je l’ai vécue en déjeunant avec Jérome Delabarre le mardi 5 mars 2013.
Jérôme est en charge de l’équipe outils et industrialisation (RET/API/TDP) à la Société Générale. Et alors que je bats la campagne depuis maintenant quelques années pour parler Cloud et DevOps, lui et son équipe expérimentent avec succès le déploiement automatisé d’applications et d’infrastructures en faisant voler en éclats de façon très pragmatique la rigidité des silos entre développement et production. Sur le plan philosophique cela consiste à étendre la boucle du développement agile en rajoutant au principe de « Continuous Integration» un principe de « Continuous Delivery ».
Retour sur un projet qui date de juin 2010
A l’époque l’objectif consiste à accélérer le déploiement des applications en automatisant au maximum toute la chaine de fabrication des éléments constitutifs du SI, établissant de facto un pont entre les études et la production. L’enjeu est de réduire la durée du cycle Développement/Production et d’accélérer la livraison des releases applicatives. Dit plus simplement, l’objectif est de diminuer drastiquement le délai nécessaire à une ligne de code pour passer toutes les étapes entre le poste du développeur et la machine de production.
Pour cela trois éléments déterminants :
Un mantra : « De quoi mes applications ont-elles besoin pour fonctionner ? »
Une philosophie : l’Approche Top Down (c’est l’application qui commande)
Un arsenal : un outil de modélisation des processus de mise en production et du document d’architecture applicative, un orchestrateur et un référentiel de composants.
Bref une approche très, très DevOps, mise en pratique de la façon suivante :L’application et son mode de déploiement / instanciation sont modélisés pour tous les environnements nécessaire à la gestion du cycle de vie d’une application, de l’environnement d’homologation jusqu’à la production. Ce modèle s’appuie ensuite sur un moteur d’orchestration et le référentiel de composants pour enchainer sans aucune intervention humaine toutes les étapes de la mise en production. Lorsque la décision est prise de passer d’une étape à une autre (passage de QA à pré-prod par exemple), le processus automatisé récupère des packages applicatifs qui sortent des usines de développement (placés dans une DSL). Il les déploie ensuite en déposant sur l’infrastructure provisionnée pour l’occasion, et selon la séquence déterminée, toutes les briques logicielles, le code et les éléments de configuration. L’application est dans la même séquence « remontée » avec tous les pré- et post- traitements nécessaires. Les retours arrière sont même prévus !
Bilan des courses
A ce jour 80 applications métiers et les releases associées sont livrées de façon entièrement automatisée. Pour supporter cela, le catalogue de composants manipule aussi bien de l’Apache, que du Weblogic, du Weblogic portal, du Websphere, de Oracle (ddl, dml, plsql) , de Informatica, du Cristal, ou encore du Tibco. Cerise sur le gâteau, afin d’assurer un service à 360°, Jérôme et son équipe gèrent aussi avec le même outillage le cycle de vie et MCO des plateformes qui supportent les applications.
Les bénéfices ?
Réduction drastique du « time to value », augmentation du nombre de releases passées en production, amélioration significative de la productivité, diminution des erreurs et augmentation consubstantielle de la qualité des mises en production. Tant sur le plan des processus de collaboration inter-équipe que l’industrialisation complète de la chaine de mise en production, c’est tout bonnement impressionnant.

DSI : le catalyseur de la transformation de l'entreprise

A lire sur:  http://www.infodsi.com/articles/139322/dsi-catalyseur-transformation-entreprise.html
 

mardi 12 mars 2013

Selon une étude de Forrester Consulting commanditée par Colt Technology Services, le manque de contacts et d'interactions entre le département IT et les services en lien direct avec le client ralentit la transformation de l'entreprise et freine le renforcement de son avantage compétitif.

Soumises au besoin constant d'optimiser l'efficacité des effectifs et de fournir des données sur les clients en temps réel, les entreprises s'appuient de plus en plus sur l’IT pour conforter leur avantage compétitif. En France, 78 % des DSI français collaborent régulièrement avec le département financier, 54 % avec les départements marketing et 26 % d’entre eux avec les départements commerciaux, alors que ceux-ci achètent de plus en plus leurs propres services et infrastructure IT.

Oui, mais voilà, plus 6 DSI sur 10 perçoivent comme une menace pour leur fonction le fait que d'autres départements acquièrent leurs propres services IT. Ce chiffre atteint même 82 % en France. Ce phénomène est d'autant plus inquiétant que la moitié des DSI estime toujours que les autres dirigeants n'ont pas conscience de la façon dont la technologie peut s'inscrire (ou non) dans la poursuite des objectifs de l'entreprise. "Le futur DSI a un rôle central à jouer dans la transformation des métiers de l'entreprise, insiste Julie O’Hara, Vice-présidente des services et solutions chez Colt. Lorsque la collaboration s'intensifie avec les départements commerciaux et marketing, le DSI peut approfondir sa compréhension de la stratégie de l'entreprise, et par la suite, mieux expliquer la capacité des services IT à apporter de la valeur ajoutée au consommateur final". L’étude révèle en effet que les entreprises ont besoin d'accéder aux meilleures informations du marché, souvent en temps réel, notamment sur le comportement des consommateurs, l'activité de leurs concurrents et leurs résultats commerciaux.

Plus de la moitié (56 %) des DSI interrogés reconnaissent d'ailleurs que le besoin croissant de se familiariser avec les différents secteurs d'activité constitue un défi auxquels ils vont devoir s'attaquer. "Sur le marché, on constate qu’un DSI qui comprend le fonctionnement de chaque département et les interactions entre ceux-ci, ainsi que les objectifs stratégiques de leurs clients et fournisseurs, s'impose comme un catalyseur de la transformation de l'entreprise et fait évoluer son département en un prestataire de services interne, aidant toute l'entreprise à proposer une meilleure expérience utilisateur et à se démarquer davantage" conclut Julie O'Hara.

Source: infoDSI.com

4 Tips for Project Communication

A lire sur: Method 123
 

If you're working on projects, then read on to learn these...

Back in the 60', Motown's "I Heard it Through the Grapevine" was a huge hit, made famous by Marvin Gaye's recording. Even though he himself is no longer with us, the grapevine he sang about is alive and well, as it's a timeless metaphor for the way news travels.

In a project environment, the circulation of unofficial information and rumors is enough to make heads spin. We set up official communication plans that detail who knows what and when, but struggle with managing the unofficial information. The following are tips to stop the confusion and manage the grapevine effectively:

Tip 1 - Become Part of the Grapevine
People love talking about what goes on within their work environment. The grapevine truly does exist in all companies. Assume the projects you manage are one part of that conversation, insert yourself into it and ask people what they are hearing about your projects. Is there any news from above? Are resources happy? Then, be sure to add your own facts into the mix. A little bit of accurate information never hurt anyone.

Tip 2 - Combat Negative Messages with Facts
Negative communication sometimes gets spun into a mile-long email thread. Inaccurate information and intensity of emotion continue to escalate the longer the email thread grows. The best antidote to negative communication is to get the facts out there as quickly as possible. Compose a thoughtful and precise "Reply All" with a handful of relevant facts to get everyone in sync. Then, kill the thread and take it offline.

Tip 3 - Stop the Bad Press
Most talk on the grapevine is harmless, primarily serving as an interesting diversion during a long day at work. People don't really pay that much attention to it. However, innocuous gossip can turn into hurtful and malicious slander. You need to track down the source of that information immediately and make it stop. Find out why someone feels compelled to put forth such negative propaganda about your project and deal with it face-to-face.

Tip 4 - Fill the Vacuum
You may have projects that aren't impacted by negative communication. However, you are left with a vacuum of communication. It's up to you to fill this void with positive and factual information about your project. Send out pertinent emails, give appropriate updates at company meetings, and have one-off conversations. That way, people will really have something to talk about when your project gets tangled up in the grapevine.

The grapevine has been around since the time the 3rd person walked on this Earth. There's nothing you can do to stop it from happening, so include it as part of your unofficial communication plan. You'll notice a big difference with the buzz on your projects.

En quoi consiste la gouvernance des flux de données ?

A lire sur:  http://www.decideo.fr/En-quoi-consiste-la-gouvernance-des-flux-de-donnees_a5952.html

Paul French, Axway, Vendredi 1 Mars 2013

La gouvernance informatique n'est pas une nouveauté. Lorsque cette démarche d'entreprise apparut il y a plusieurs années, elle était animée d'un noble dessein : mettre en adéquation les intérêts de l'infrastructure informatique avec ceux de l'entreprise ; la protection du système d'information et la maîtrise du budget informatique étaient secondaires. La notion de gouvernance s'est rapidement imposée auprès des entreprises comme une nécessité à leur bon fonctionnement. Elle s'est dotée au fil du temps de méthodes, outils et bonnes pratiques ; l'infrastructure, le reporting et des catégories complètes de solutions lui ont été dédiés. Or, dans la plupart des cas, l'adéquation des intérêts de l'infrastructure informatique avec ceux de l'entreprise fut reléguée au second plan, derrière la gestion des risques qui devint la priorité.

Paul French, VP Strategy, Axway

0
inShare

L'infrastructure informatique devait évoluer pour répondre à ces nouvelles exigences en matière de sécurité et permettre d'agir sur l'usage, depuis le contrôle d'accès jusqu'à la disponibilité des données. Mais la gestion et le contrôle des risques informatiques se sont mis en place au détriment de l'agilité de l'entreprise. Le prix à payer s'est avéré trop élevé.

Nous avons donc tenté de concilier le meilleur des deux mondes - contrôle et flexibilité. Dans ce contexte, les architectures orientées service (SOA) occupaient une place de choix, apportant la promesse d'une disponibilité, d'une réutilisation et d'un contrôle accrus, conjugués à une nouvelle définition de la gouvernance. Balayant un champ plus large que la seule gestion des risques, ce nouveau modèle de gouvernance devait garantir un contrôle total tout en réduisant l'exposition aux risques. Le paradis nous attendait.

Malheureusement, cela n'était pas le cas. Nous avons rapidement réalisé qu'il existait une limite à notre capacité de contrôle. Les individus, les partenaires commerciaux et les processus métier complexes avaient du mal à entrer dans le royaume de la gouvernance SOA. Nous étions proches du but, mais il nous restait du chemin à parcourir. Nous avions simplement omis de distinguer la gouvernance de l'art de gouverner.

Pour schématiser, la gouvernance consiste à établir des règles et suppose de faire confiance à tous les participants concernés (systèmes, applications, partenaires commerciaux ou autres) pour les appliquer et de contrôler à postériori qu'ils les ont bien suivies. Gouverner consiste à utiliser ces mêmes règles et de faire en sorte qu'elles s'appliquent tout au long du déroulement des processus concernés. Prenons un exemple issu de la vie quotidienne. Interdire à ses enfants de manger des biscuits avant de passer à table, est une démarche de gouvernance de leur régime alimentaire.

Dans ce cas, vous comptez sur eux pour agir selon les règles que vous leur avez fixées. À l'heure du dîner, vous saurez si vos enfants ont bien suivi la consigne. Ont-ils fini leur repas ? Avaient-ils des miettes de biscuits sur leurs vêtements ? Manque-t-il des biscuits dans la boîte ? Vous avez défini une procédure claire et vous avez espéré qu'elle serait suivie. Mais au bout du compte, l'analyse de ces données ne vous permet que de constater le résultat ; rien n'a été mis en œuvre pour garantir l'obtention du résultat souhaité.

Gouverner exige une démarche plus proactive. Vous devez toujours établir les règles dès le départ, analyser les données en bout de chaîne pour vous assurer que les règles ont été respectées et apporter des possibilités d'amélioration continue. Mais gouverner exige le contrôle des flux tout au long du processus. Pour reprendre l'exemple de la gouvernance alimentaire, nos enfants ont toujours les mêmes règles à suivre, mais à présent, ils disposent également de rails pour les guider et les aider à atteindre le résultat escompté. Ils ont envie d'un biscuit avant le dîner? Qu'ils le remplacent par une pomme !

L'art de gouverner étend le champ de la gouvernance informatique. Il s'agit de définir les attentes et les résultats souhaités, de mettre les participants en relation avec le processus, de contrôler le flux de données afin de garantir la réalisation des objectifs définis et d'analyser les résultats. Le verbe « gouverner » fait référence à l'action qui concrétise les objectifs de la gouvernance. Il recouvre la définition des attentes et des paramètres à utiliser, la mise en relation des participants dans les flux et l'analyse des flux par rapport aux attentes. Mais il englobe aussi une étape précédemment absente : le contrôle au moment de l'exécution.

Gouverner implique un contrôle sous-jacent. Ce contrôle transforme les règles en réalité, engage les participants en fonction de leur workflow (manuel ou automatique, en temps réel ou différé, sur terminal mobile ou poste de travail) et établit une cohérence par rapport aux attentes définies. Gouverner implique une attitude active, alors que la gouvernance est -en grande partie- passive.

What to consider before moving your application to the cloud

A lire sur:  http://www.techrepublic.com/blog/programming-and-development/what-to-consider-before-moving-your-application-to-the-cloud/6465

By Justin James, March 7, 2013, 10:11 PM PST

Takeaway: When CXOs ask developers whether they can move their application to the cloud, these are the six factors they should think about before answering that question.

In the last several years, moving applications to the cloud has gone from a big risk that only a few companies could justify to a sensible alternative to self-hosting an application. Here are some things you need to look at to determine if your application can or should be moved to the cloud. Perhaps only one or two of them stand in your way, and you can re-engineer those.

Network needs

If your application needs a high bandwidth or extremely low latency connection to systems within your network, it is not likely to be a good candidate for being moved to the cloud, unless you can also move those other systems to the same area. On the other hand, a good cloud provider is likely to be able to provide high bandwidth, low latency delivery to your users if they are not in-house users. Maintaining that kind of network is a headache, and it can be a joy to let someone else deal with it. The more you can keep the data transfer to being within the application and not between the application and the screen, the more suitable your application is for the cloud.

Publicly usable

If the application will be used by people outside of your organization, moving your application to the cloud gives you two major benefits. First, it moves your network needs off of your network. Second, it creates complete separation between your internal network and your application. While many IT departments will do this anyway, I have seen IT departments that have not done it (often for good reasons), which creates a security risk.

Scaling needs

Applications that need to scale or that may need to scale are good candidates for the cloud. One thing the cloud can do really well is provide you with resources on-demand. Advanced providers will have the facilities to let you schedule additional capacity for peak hours or to detect high loads and bring extra resources online.

Architecture

Not all applications can just be deployed to a server in the cloud and run. For example, some applications depend on other systems that just are not available in the cloud or can’t be located there. If your application relies solely upon standard, commodity technologies (Windows or a common Linux distro for the OS, MySQL, Microsoft SQL Server, or Mongo DB for data, and ASP.NET, PHP, Java, or Ruby on Rails for the application language), then it is a great candidate for moving to the cloud.

Storage

One thing I detested dealing with during my various system administrator jobs was storage. And not just “where do we put all of this data?” either — even more frustrating than that was backups. To make it worse, systems would get slow, and the issues were traced to I/O speeds, but solving those issues was not the easiest or the cheapest thing in the world. Applications that have demanding storage needs are the kind that are nice to send into the cloud.

Business model

Cloud providers almost universally charge based on the resources you use: storage, number of servers online for how long, bandwidth, and add modifiers based on the capabilities of those resources (the more RAM per virtual machine the more you pay, for example). If your business model cannot monetize your users in a way that scales with your cloud costs, you are going to be sunk quickly, unless your profit margin is so high that all but the heaviest users are profitable, and heavy users need to be rare. Things like perpetual licenses are deadly when you are paying for cloud resources on a monthly basis.
J.Ja