Yoav A
Projects Management Professional | TopLinked.com | MyLink500.com | LION | 8200+
What top ten actions can IT project managers take to increase the likelihood of implementation success?
What suggestions could you suggest that project managers will find helpful in ensuring success?
Drawing from your ideas, what are the top ten list of actions most likely to lead to implementation success?
Thanks,
Yoav Aviv
OPEN Networker: avivy@israeli-it.com
Projects Management Consulting for Fortune 100 Companies EVPs | TopLinked.com | MyLink500.com | LION
Answers (148)
Stolen from communicationideas.com:
"The most important lesson of all is that change is not about technology, or systems, or procedures, or cost. Change is first and foremost about people. Even when the change is due to the introduction of new technology, it is still about people, not technology. A change initiative that does not pay attention to people will almost certainly fail. Most of the reengineering efforts of the nineties failed because they focused on the procedural aspects of work, ignoring the crucial human side. "
Links:
Strong top management support. because th biggest challenges are often internal.
Top ten :
- Go Agile
- Go Agile
- Go Agile
... do I have to continue :)
Agile development already encompasses all the best techniques, actions and psychological aspects of getting from the idea to its implementation in the simplest, most safe, most profitable way.
Extreme programming integrated with Scrum is the best combination in my experience.
...always understand what phase of the project you're in,..
...make sure the preivous phase is finished before you progress...
...always know where you going to, so you know when you've got there..
...understand what needs to be done to get there...
...prioritise your issues and try to solve the top 3 each week...
Not necessarily in order of importance, here are what I have found to be important in delivering successful IT projects:
1. Have a strong Change Control process that all the stake holders agree to and respect to the letter. Keep it simple but ensure all changes are captured, dealt with and reported. The biggest risk to any project is changes to requirements that generate re-work and delays.
2. Have a good business analyst to capture requirements and ensure this BA has access to actual end users of the intended system. Any layer of indirection between end users and BA increases the risk of important details being lost.
3. Ensure that 'rainy days' scenarios are captured as well as 'sunny days' ones: error handling quite often represents half the code in a system so if you don't plan for it, you don't plan for half your project.
4. Ensure all the stake holders report good and bad things to you in a timely fashion, or in the words of a project manager I used to work with: "it doesn't matter if news are good or bad, I don't want any surprises".
5. Don't under-estimate testing, whether it'd be unit, system, integration, performance, user acceptance or any other testing. Once you've estimated it, double your estimate and don't forget defects will have to be corrected which will add more development and regression testing.
6. Corollary to 5: make sure you have a good defect tracking system and a good test manager.
7. If possible, release your system in small manageable iterations rather than one 'big bang' release to get feedback early and ensure you can take corrective action if needed.
8. Ensure you have a good architect who understands the technology you're using and will take the role of the 'surgeon' as described in The Mythical Man Month by Fred Brooks.
9. Don't believe a salesman who says 'our product is the best thing since sliced bread and can do everything you need'. Get your trusted architect to talk to their techies and qualify that claim.
10. Take the whole team out for a drink from time to time and make sure they feel comfortable talking about everything, good and bad.
And number 0: don't forget the KISS principle.
I think a project manager should focus his efforts, as one of the top 10 action, maintaining a good-living environment within the project team. I mean that when a working group works fine togheter, the implementation of success process is at a good point.
After all, the employee selection has already been made in previous stages (when the team is built up) so when a group is not working well it's because a strong leader hadn't show the way to cooperation (not because lack of skills), or at least this is the way I see it.
So, definitly, I will put "Internal Team Relashionship" as one of the top 10 action to take into consideration.
Hi,
I absolutely agree with Katharine, Mohammed Issa and Simone. I can order it as follows:
1. Quality Resources - It is about having skilled and professional people
2. Client and Requirements - make sure you understood client and crystal clear about requirements
3. Process - the implementation process till delivery and acceptance is understood and accepted by both the service requester and provider. Make sure the process planned supports agile development
4. Proper management support - take the word of Issa
5. Other elements management - Other elements like co-ordination, process and environment setup, involving team in the process right from requirements phase, etc. All play crucial role in success.
Patricia G
Analyst, Programmer and Pioneering Thinker - Available Now
Best Answers in: Using LinkedIn (4), Mentoring (1), Compensation and Benefits (1), Employment and Labor Law (1), Career Management (1), Small Business (1)
I find it is important to engage the confidence of your customer. When he/she has confidence in your ability to deliver he/she will not hassle you, and will leave you (and your team) to get do with what you do best. I cannot suggest how you acquire their fervent support, I just know that without it the project is doomed.
Patricia, I think you can get your customers support by showing them that you embrace change. Build software in an agile way, select user stories which you can complete in a Sprint (2, 3 weeks) and show it to your customer, so that he/she can provide early feedback. This way the customer will certainly feel more confident.
Here is my IT implementation top ten list:
1. Be familiar with the technology/product you have to implement.
2. Know the business goals and pains of your customer and try to "read between the lines" in your meetings and workshops. Ask and manage your customer.
3. Create a Work Breakdown Structure (WBS) and let it sign by the customer. This is the scope of the project. You need this to avoid a creeping scope in a later phase of the project.
4. Identify all stakeholders of the project and most impotant the sponsor on the customer side. You will need them during the phases of the project.
5. Build a project plan to identify your critical resources. All your resources must be funded and you should have an experienced project management team.
6. You have to plan control cycles to check your budget and timeframe which was agreed and documented with your management and with the customer from the beginning of the project.
7. Build in milestones and checkpoints your sponsor has to agree with.
8. Don't forget to plan a data conversion project (this should be a seperate project). Data quality is a critical issue.
9. Be sure that all business requirements have been met at the end of the project.
10. Obtain a formal customer acceptance of the project (and of all project tracks).
Links:
Matt G
Owner at Mattutes Ltd
Best Answers in: Risk Management (1), Offshoring and Outsourcing (1), Corporate Governance (1), Project Management (1)
- Be a pessimist, it always pays off
- Ask stupid questions, lots of them
- If you commit to something, deliver it
- Speak s-l-o-w-l-y to people who's first language isn't English
- Keep all results and commitments transparent
- Whenever there's an action, note down the owner and the deadline (very often overlooked that one).
- Leave time for planning, it takes longer than you think
- Always pull stuff in, never push stuff out
- Don't lie about project progress
- Say "thank you" and "well done" whenever appropriate
...all in no particular order.
Gregory G
Concentrates on using IBM Technologies to simplify IT in small to mid-size companies.
This is in a pseudo - order of least to worst.
1. Make sure the corporate sponsor has the power to make decisions when they need to be made.
2. Quote project management and status update time into the project (or it gets pushed to the wayside because it's not considered part of the project)
3. Define the end of the project. I've seen too many IT projects languish for lack of a hard stop.
4. Make the customer pay for the upfront investigative work. A solid quote cannot be given if the project is not adequately defined. While getting a "free" definition is nice, your customer will value the definition, and it's completeness, better if they pay for it.
5. Sit down, write down, and analyze ALL project assumptions on both sides. Incorrect or misplaced assumptions can kill any project, even if it's done right in someone's eyes. Talk through the assumptions.
6. Handle Change orders in a logical fashion. Make them go through one person, get them approved, and the unapproved ones can become a springboard for Phase II.
7. Don't assume IT people can project manage complex IT projects. They are different skill sets. Many IT projects die because they are not properly managed by trained PM's.
8. Don't let IT dictate the technology used on the project. IT can have a tendency to use bleeding-edge, unproven or "Favorite" technology instead of what is absolutely right for the project.
9. COMMUNICATE. Build a communication matrix. Talk to people via email, bulletin board, phone, web-meetings, in person, etc. Use your matrix to communicate the information in a timely and accurate manor.
10. Handle your Risks. So many times we stick our heads in the sand and ignore the risks of a project. Write them down, rank them, analyze them and then handle them. This is time well spent.
Obviously there are others, but these are the big 10 for me.
Greg
IT Service Management Foundation
Professional Communication Foundation
Project Participation Foundation
Business Information Management Foundation
Links:
Rob B
Technology/Business Process Management Consultant
Best Answers in: Organizational Development (2), Purchasing (1), Economics (1), Government Contracts (1), Government Policy (1), Government Services (1), Exporting/Importing (1), Internationalization and Localization (1), Business Analytics (1), Labor Relations (1), Non-profit Management (1), Market Research and Definition (1), Energy and Development (1)
1. Make sure that the project is aligned with a valid and up-to-date technology business case. Successful implementation means more than on-time, on-budget, no significant defects. It means the project recovers its cost quickly and delivers measurable business value.
2. Establish solid, consistent communications among sponsors, developers, vendors, and all significant stakeholders.
3. Establish an independent quality management process that (a) does not report to the project manager, and (b) focuses on ensuring quality in PRE-implementation deliverables, i.e. requirements, functional specs, and technical specs.
4. Find and fix pre-implementation defects as early as possible after they are created. Requirements reviews and walkthroughs can find and fix defects at a fraction of the time and cost they would require if found in testing.
5. Include testing specifications in requirements definitions. A requirement that cannot be tested with a binary test (yes, it passed vs, no, it failed) is not complete. Plus, testing specifications are invaluable thought models for functional and technical specs
6. Integrate Agile principles and methods with plan-driven principles and methods as appropriate. Whether or not they like to talk about it, Agile project managers know how to do this.
7. Do whatever you have to to keep response times within agreed-on parameters. Excessive wait times for needed feedback from sponsors and stakeholders can kill a schedule, and maybe endanger the business case itself.
8. Have a backup ready to replace any key resource who leaves or any critical technology component that is late in delivery.
9. Before integration testing, perform code inspections, reviews and walkthroughs Next to requirements reviews and walkthroughs, code inspections, reviews and walkthroughs will find and fix defects faster and at lower cost than any other process.
10. Make sure that the project has an Exit Champion, someone whose job iincludes identifying when and if the project should be rescoped, rescheduled or scrapped. Successful projects depend on the avaiability of finite resources. A project that is unlikley to succeed is a drain on resources that could be used elsewhere.
Here's a list I have always found good to work to
1. Stakeholder buyin/management
2. Follow standard principles & procedures
3. Define with sponsor and stakeholders what is the project success before you start
4. Once project has started avoid scope creep and keep changes to a minimum, if changes happen communicate early and use change control
5. Organise the project resources according to project strategy
6. Monitor and reporting using critical path and checkpoints
7. Keep sponsors and stakeholders engaged and involved - treat them like a project resource
8. Report & Test. Report & Test
9. Openly and activley delegate non PM functions
10 Upon completion, evaluate for future project success and for lessons learned
First you have to have executive/management buy-in, after that it's in the hands of your IT team.
If you haven't already, I would suggest you read Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister. This book has helped me out immensely when it comes to successful projects.
Links:
YYRenee L
Telecommunications Professional PMP
Best Answers in: Staffing and Recruiting (1), Business Development (1)
I think carefully investigating the scope and requirement would reduce a lot of the workload in the middle of the end of the changes and hassle. Carefully manage those critical path and milestones increases your chances of either meeting the deadline or even better earlier than the deadline.
Then, carefully elaborate and inform your customer of the progress may contribute to less changes and less misunderstanding
Keep track of your suppliers and your backup plans to make sure your resources is always there when you need them, and avoiding the schedule slip.
Finally, actually it should be the first one, take care of your team members make sure they have good understanding of how important they are to the task and how important it is to meet the deadline.
That is my opinion
There is an old saying which I feel is apt for all IT projects.
"If you don't know were you are going any road will do"
It is vitally important to agree from the outset (A). the project objectives and (B) who is accountable and responsible for its effective delivery. Remember the IT operation is an enabler of the business needs. IT while playing a huge roll in any project is only one part of the link the other two parts are the people(Business) and the processes(the end Game) all these have to work together to deliver. One final point is to ensure constant communications to all interested parties.
Keepint things simple also helps
1. Get the right people involved in the right roles.
2. Break the project down into tasks that take a week or less.
3. Track progress by task completion. Any task late was caused by an underlying problem. Uncover the problems and your project will be completed on time.
4. Know whom to escalate problems when needed.
5. Break large teams down into subcommittees or sub-teams.
6. Validate every piece of work as soon as it is done. Waiting to validate the entire project at the end increase the risk that the wrong product was delivered.
7. Define required service levels to ensure that the infrastructure meets response times and disaster recovery point and time objectives.
8. Keep a detailed issues log to make sure all i's an t's are dotted and crossed.
9. As Abe Lincolon said: "You cannot be liked by all the people all the time". Be prepared to deal with conflict and criticism. Be respectful and couteous to all. Strive to be liked by all. Regardless, the most imporant fact is completing on time and delivering the right product.
10. Prepare for transition of the product to a steady state of production. Prepare an annual budget for running the new product.
Links:
Gary N
Information Technology and Services Professional
Best Answers in: Business Analytics (3), Organizational Development (2), Project Management (2), Writing and Editing (1), Corporate Governance (1), Change Management (1), Planning (1)
The top 5 of 10 are the same - Cummunication!
1 Communication - make sure you're understood, that there's no ambiguity and that you understand others
2 Communication - communicate with the right people, at the right time, in the right way for them (so build a communications plan based on a stakeholder power/interest grid and, where possible, figure out which people are visual, which are auditory or kinesthetic, etc. and develop a plan that matches their primary representational system).
3 Communication - of responsibilities and expectations - make sure participants know what's expected of them and when and how.
4 Communication - ensure no surprises philosophy - for neither you as PM, nor the project sponsor.
5 Communication - of what the end goal is. Make sure everybody knows why a project is being undertaken and how its success will be measured - no point focussing on cost andtime if critical functionality is missing.
6 Benefits - make sure that somebody has responsiblity for ensuring that the intended benefits of the project are clearly understood, are realistic and that they are achieved (no point having a new system if nobody uses it).
7 Understand the politics (when there's people, there's politics). It'll make your life much better if you know he agenda of each of the key players (and better understand the power).
8 Recognise that all projects will result in a change and that how this change will affect people needs to be understood and managed
9 Plan, plan and plan (and then replan). Track progress closely and don't allow any task to be more than 5 days in size. If you have a task that's 100 days, you carry the risk on not knowing that it's delayed until the 100th day.
10 Don't schedule projects that are longer than the rate at which your business changes. There's a risk that what's wanted/needed by the business now won't be what's needed when the project is implemented in three years - the World keeps changing and so do companies, competitotrs and customers.
11 Surround yourself with competent people who have a good track record.
12 Don't limit yourself to just 10 things!
Kathy F
President of AxisPortals, Web Designer, Writer, Editor, Trainer
Best Answers in: Computers and Software (3), Blogging (2), Public Relations (1), Lead Generation (1), Organizational Development (1), Market Research and Definition (1), Enterprise Software (1)
Yoav, you've already had some terrific answers. I'll just add one that I think belongs on every top ten list.
Remember that an IT project is never only an IT project.
Now matter how sweeping or modest the project might be, it will inevitably entail shifts--and often expose systemic issues--in other areas ranging from basic record keeping to human resources, and everything in between. It can be tempting to interpret this as a frustration (after all, it generally means that things will take longer), but I think it's best to see it as a blessing, and as a way to keep IT always at the forefront of the administrative imagination. After all, getting the IT project in order often means that underlying processes that weren't working, before, will have to be brought into health, as well, and this is ultimately a good thing for the entire organization.
It depends on the project, technology and industry. But. the majority of projects fail due to:
1. Board level commitment and stakeholder sponsorship
2. Communication with Suppliers, Project Teams and the Business
2. Defining, Managing and Agreeing Scope
3. Delivering in Bite Size Chunks - Quick Wins!
4. Understanding what the project is suppose to be delivering
5. Resource capability, usually the right person for the job, isnt made available
6. Taking people where you want to go, not expecting them to find there own way
7. Decision Making
8. Knowledge Transfer
9. Realistic Planning
10. Using Independent Design & Project Assurance professionals
Good luck!
Alex
Links:
Jim P
Trusted partner, advisor, publisher, and recognized hands-on technology management leader
Best Answers in: Staffing and Recruiting (1), Computers and Software (1)
We all can differ on the best methods but almost all successful projects I have been associated with share the following key (ten (10) selected to match your question) characteristics:
1) Project has business (management) and IT sponsors who are committed to success
2) Project has clear objectives (I know this seems "goofy")
3) Requirements are clearly written and can be traced throughout the project life cycle
4) Key stakeholders are involved, and kept involved, throughout the project life cycle (e.g., business, operations, subject matter experts, software end-users, etc.)
5) Project plan is defined and adjusted as needed (see change management below) responsibilities are clearly defined. Work breakdown structure (WBS) is aligned with organizational breakdown stucture (OBS) and the alll activities rollup to a work package in the WBS
6) People are held accountable for certain activities and deliverables (defined in number 5 above)
7) Project documentation and working papers (e.g., business case, detailed planning products, project plans, architecture specification, requirements, design, configuration, data migration, integration, communication plan, business processes, training plan, "as built" specifications, maintenance and support plan, user documentation, help, etc.) are organzied and easily accessible to all stakeholders.
8) Project has a change management plan to mitigate impact of "scope creep"
9) Project has a change budget or contengency to handle agreed-upon scope changes
10) Project risks and contingencies are defined and managed through a well communicated process
Sure there are more I may have overlooked or omitted, but these are the first ten (10) that come to mind. Good luck;
-jdp
Get your requirements sorted into understandable, goal based stories.
For instance:
Judy the user wants to get an email when she has a new job.
She:
* Logs on
* Reaches her homepage
* The System asks: do you want to set up an email address?
* Judy then enters her details by following a link
The system:
* Allocates a new job
* Notices the email address subscription
* Sends Judy an email with her next actions
Repeat this. Indefinitely. Your goal should be to have a complete and utter understanding of the scenarios your project is trying to tackle, at a granular level.
That way, when a developer says "X is broken", you don't need to understand X, you just need to understand what impacts that has on your scenarios.
Scenarios also help your testers (who should work hand in hand with your BA to form said scenarios), who should be involved from the start. That way, they can help you ensure the project is succeeding.
Further, when you are talking to other clients / parties / etc - giving them the 15-20 core scenarios you are solving for them is readily and easily understandable; and it's easy.
If there is any confusion, fall back the the scenarios and expand on them just enough to clarify it.
If there is any scope creep, get them to write their own story of how things work before you accede to any demands.
This kind of approach brings clarity, minimized confusion, and avoids all of the horrible misjudged expectations.
Links:
David B
Software Architect - Lead Software Engineer - Scrum Master at Partezis
Best Answers in: Software Development (29), Web Development (8), Computers and Software (5), Databases (3), Career Management (2), Education and Schools (1), Business Analytics (1), Project Management (1), Professional Books and Resources (1), Biotech (1), Blogging (1), Enterprise Software (1), Information Security (1), Information Storage (1)
I don't have a top ten, but I certainly have a top three.
1) Get out of your programmers way.
2) Trust them. If you don't trust them, you have a serious problem in your hiring process.
3) You role as a project manager is to remove any impediment.
Rick B
Infrastructure Solutions Expert for BlueCross BlueShield of South Carolina
I don;t have 10, but these are my recommendations based upon my experience in large projects:
Identify stakeholders and engage them early.
Define and document the scope of the project and document changes to the scope WELL. Create change sheets and distribute and review ASAP.
Ensure the people who will pay for the effort know what the full economic and business impact is before initiating work
Set realistic expectations on delivery (costs and timeline) based upon the input of the stakeholders
Limit meetings and invited guests to those who absolutely are required.
Openly request any input that might make the stakeholders rethink the project and review this with senior management regularly.
Do not name drop. As a Project Manager, assuming the project you are working on is sanctioned, utilize other methods of getting action on the items you need by talking to people and bringing them into the discussion about why it is important to the company, not that Mr. Bigstuff CIO says its important.
1. Lock in your project Scope.
All participants must publicly acknowledge acceptance of agreed scope details before any work proceeds.
Scope-Creep will kill your project deader n' disco... as it were.
2 - 10. Hire smart, dedicated & professional employees, and provide financial incentives for meeting project deadlines on-time.
Success
Jeff B
Report Optimization Specialist and Owner, Creative Sound Entertainment
Best Answers in: Government Policy (1)
One MAJOR thing to remember is Pilot, Pilot, Pilot. Make absolutely sure that no process or software implementation, no matter how mundane, is launched without adequate pilot testing. I can't tell you how many half-baked solutions I've seen distributed company-wide that didn't have adequate testing that would have been extremely successful had the time just been taken to thoroughly pilot the program.
Roland H
Owner/CEO at Palmtree Software Development Ltd.
Best Answers in: Job Search (1), Government Policy (1), Computers and Software (1), Using LinkedIn (1)
Set the project goals and don't change them, and if you absolutely have to change the goals, don't just abandon them without picking a new one.
Communicate these goals to your clients and team in clear, unambiguous form and not only once, but frequently.
Trust your team, and stand by them, don't abandon them, and tell them everything about the project (no "secrets") that may impact their work.
Rather tell them more than less - you trust them after all.
Don't abandon the client, help him to do his own part of the project.
In my opinion these are the most important ones, the rest - gant charts, methods, etc.- are just tools.
Clarification added April 22, 2008:
Certainly, beside this you need a capable team, a project that can be finished with sensible deadlines and everyone has to do his part, otherwise your efforts will be in vain
1. Empower the users (as Kartharina mentioned PEOPLE) by ensuring continuous training sessions.
2. Win their confidence - By acting on at least one request on regular basis.
