7 Tips for Improving the Daily Scrum

January 12, 2009

Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: “What did you do since the last meeting?”, “What are you going to do until the next meeting?”, “What impedes you from being more productive?”. The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

1. Standup means stand up, no sitting, really.
Standing up on the daily Scrum draws attention to the brevity of the meeting. The purpose of the meeting is synchronization and no lengthy problem solving. Standing helps to remember that problem solving except the smallest one has to be taken offline – nobody likes to stand for an hour while two guys are arguing about the protocol implementation details.

2. Keep it short. 15 minutes max.

Everybody can spend 15 minutes a day on synchronizing with the others. Especially if it happens to be immediately before or right after the lunch time. Spending half an hour is a very different story. In my experience most of the time the 5-6 person teams are usually done in just 7-10 minutes.

3. Stand in front of the visual progress artifact.
Ideally in front of the task board together with the product and sprint backlog. Visuality and tangibility help discussing things. If task board is used, developers often like waving hands towards the card being currently discussed or even move the cards during this meeting

4. Everybody should be present.
One of the main reasons for meeting live is to utilize as wide communication bandwidth as possible – people are known to communicate more effectively, when meeting live. If particular team member is unable to participate, another person should report on behalf of his/her. If it is impossible for some reason, catch up later.

5. No typing.
Holding a laptop and making notes is power. The one who types immediately starts looking as a manager and often subconsciously starts writing what he thinks was meant, not what team members actually said. If you need notes, take micro-notes by hand.

6. Concentrate on the second and third question, not on the first one.
What’s done is more of a context for the second and third questions. The real point is to figure out what’s blocking the efficient work and who could help it.

7. If team talks too much to ScM, let him not too look at the team.
Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master.

Daily Scrum is a powerful tool, but as any other tool it is good, when you know what it’s useful for and have some experience in using it. The above seven simple tips can be good starting points or reminders. However, every team knows best how to adjust its standups to serve them better. The important part is the goal, not the method.

Your experience
What feels important in your daily standup?


10 Golden Rules of Project Risk Management

October 30, 2008

The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands. Also your team members will be much happier if they do not enter a “fire fighting” mode needed to repair the failures that could have been prevented.

Rule 1: Make Risk Management Part of Your Project

The first rule is essential to the success of project risk management. If you don’t truly embed risk management in your project, you can not reap the full benefits of this approach. You can encounter a number of faulty approaches in companies. Some projects use no approach whatsoever to risk management. They are either ignorant, running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Some people blindly trust the project manager, especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff.

Rule 2: Identify Risks Early in Your Project

The first step in project risk management is to identify the risks that are present in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks, people and paper. People are your team members that each bring along their personal experiences and expertise. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. They can reveal some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. Paper is a different story. Projects tend to generate a significant number of (electronic) documents that contain project risks. They may not always have that name, but someone who reads carefully (between the lines) will find them. The project plan, business case and resource planning are good starters. Another categories are old project plans, your company Intranet and specialised websites.
Are you able to identify all project risks before they occur? Probably not. However if you combine a number of different identification methods, you are likely to find the large majority. If you deal with them properly, you have enough time left for the unexpected risks that take place.

Rule 3: Communicate About Risks

Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. The frightening finding was that frequently someone of the project organisation actually did see that hammer, but didn’t inform the project manager of its existence. If you don’t want this to happen in your project, you better pay attention to risk communication.
A good approach is to consistently include risk communication in the tasks you carry out. If you have a team meeting, make project risks part of the default agenda (and not the final item on the list!). This shows risks are important to the project manager and gives team members a “natural moment” to discuss them and report new ones.
Another important line of communication is that of the project manager and project sponsor or principal. Focus your communication efforts on the big risks here and make sure you don’t surprise the boss or the customer! Also take care that the sponsor makes decisions on the top risks, because usually some of them exceed the mandate of the project manager.

Rule 4: Consider Both Threats and Opportunities

Project risks have a negative connotation: they are the “bad guys” that can harm your project. However modern risk approaches also focus on positive risks, the project opportunities. These are the uncertain events that beneficial to your project and organisation. These “good guys” make your project faster, better and more profitable.
Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work that needs to be done quickly. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Make sure you create some time to deal with the opportunities in your project, even if it is only half an hour. Chances are that you see a couple of opportunities with a high pay-off that don’t require a big investment in time or resources.

Rule 5: Clarify Ownership Issues

Some project managers think they are done once they have created a list with risks. However this is only a starting point. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign a risk owner for each risk that you have found. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. The effects are really positive. At first people usually feel uncomfortable that they are actually responsible for certain risks, but as time passes they will act and carry out tasks to decrease threats and enhance opportunities.
Ownership also exists on another level. If a project threat occurs, someone has to pay the bill. This sounds logical, but it is an issue you have to address before a risk occurs. Especially if different business units, departments and suppliers are involved in your project, it becomes important who bears the consequences and has to empty his wallet. An important side effect of clarifying the ownership of risk effects, is that line managers start to pay attention to a project, especially when a lot of money is at stake. The ownership issue is equally important with project opportunities. Fights over (unexpected) revenues can become a long-term pastime of management.

Rule 6: Prioritise Risks

A project manager once told me “I treat all risks equally.” This makes project life really simple. However, it doesn’t deliver the best results possible. Some risks have a higher impact than others. Therefore, you better spend your time on the risks that can cause the biggest losses and gains. Check if you have any showstoppers in your project that could derail your project. If so, these are your number 1 priority. The other risks can be prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Whatever prioritisation measure you use, use it consistently and focus on the big risks.

Rule 7: Analyse Risks

Understanding the nature of a risk is a precondition for a good response. Therefore take some time to have a closer look at individual risks and don’t jump to conclusions without knowing what a risk is about.
Risk analysis occurs at different levels. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. Looking at the effects, you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs, lead time or product quality. Another angle to look at risks, is to focus on the events that precede a risk occurrence, the risk causes. List the different causes and the circumstances that decrease or increase the likelihood.
Another level of risk analysis is investigate the entire project. Each project manager needs to answer the usual questions about the total budget needed or the date the project will finish. If you take risks into account, you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. A similar exercise can be done for project costs.
The informaion you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks.

Rule 8: Plan and Implement Risk Responses

Implementing a risk response is the activity that actually adds value to your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other rules have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that focuses on the big wins.
If you deal with threats you basically have three options, risk avoidance, risk minimisation and risk acceptance. Avoiding risks means you organise your project in such a way that you don’t encounter a risk anymore. This could mean changing supplier or adopting a different technology or, if you deal with a fatal risk, terminating a project. Spending more money on a doomed project is a bad investment.
The biggest category of responses are the ones to minimise risks. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. A final response is to accept a risk. This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively expensive. Just make sure that it is a conscious choice to accept a certain risk.
Responses for risk opportunities are the reverse of the ones for threats. They will focus on seeking risks, maximising them or ignoring them (if opportunities prove to be too small).

Rule 9: Register Project Risk

This rule is about bookkeeping (however don’t stop reading). Maintaining a risk log enables you to view progress and make sure that you won’t forget a risk or two. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3).
A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). Most project managers aren’t really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off, especially if the number of risks is large. Some project managers don’t want to record risks, because they feel this makes it easier to blame them in case things go wrong. However the reverse is true. If you record project risks and the effective responses you have implemented, you create a track record that no one can deny. Even if a risk happens that derails the project. Doing projects is taking risks.

Rule 10: Track Risks and Associated Tasks

The risk register you have created as a result of rule 9, will help you to track risks and their associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks or to generate, select and implement responses.
Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks are more likely to happen? Has the relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value.
The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. However, keep in mind that you can always improve. Therefore rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk management efforts and continuously implement improvements to make it even better.

Success with your project!

Source: http://www.4pm.pl


Top 10 Clues That You Are Management Material

October 27, 2008
  • 10. You like not doing anything
  • 9. You have no trouble telling others what to do
  • 8. Work fascinates you – you can sit and watch it for hours
  • 7. You like ’sweating the small stuff’
  • 6. You have always been something of a loner
  • 5. You don’t think ‘plan’ is a four-letter word
  • 4. Your favorite cocktail is milk of magnesia
  • 3. On Halloween you dress up as Alex P. Keating
  • 2. Your favorite horror writer is Tom Peters

And the number one clue you are management material -

  • You enjoy having people despise you just for doing your job.

Source: http://management.about.com


21 Precious Tips for Project Managers

October 22, 2008

Browsing the web I’ve found these amazing tips that in most of cases we all know but we never practice or remember them.

Right after I post it, I’m going to print it out and put in front of me in my desk to look at them every single day. Really worth a read.

  1. Fix the problem, not the blame. It is far more productive, and less expensive, to figure out what to do to fix a problem that has come up than it is to waste time trying to decide who’s fault it was.
  2. Tell people what you want, not how to do it. You will find people more responsive and less defensive if you can give them guidance not instructions. You will also see more initiative, more innovation, and more of an ownership attitude from them develop over time.
  3. Manage the function, not the paperwork. Remember that your job is to manage a specific function within the company, whatever that may be. There is a lot of paperwork that goes with the job, but don’t let that distract you from your real responsibility.
  4. Don’t DO Anything. Your job as a manager is to “plan, organize, control and direct.” Don’t let yourself waste valuable time by falling back on what you did before you became a manager. We know you enjoy it and you are good at it. That’s why you were promoted. Now you need to concentrate your efforts on managing, not on “doing”.
  5. You never have to make up for a good start. If a project or a job gets off to a bad start it can be difficult to catch up. Do your planning up front so you get a good start and you won’t regret it.
  6. Get out of your office. Management By Walking Around (MBWA) does work. You make yourself more approachable. You get information first-hand. You find out what’s really happening.
  7. Lead by example. If you ask your employees to work overtime, be there too. Just because company policy allows it, don’t fly first-class if your associates are in coach on the same plane. Be a leader – it’s tougher than being a manager, but it’s worth it.
  8. Delegate the easy stuff. The things you do well are the things to delegate. Hold on to those that are challenging and difficult. That is how you will grow.
  9. Don’t get caught up in ‘looking good’. “Work happily together. Don’t try to act big. Don’t try to get into the good graces of important people, but enjoy the company of ordinary folks. And don’t think you know it all. Never pay back evil for evil. Do things in such a way that everyone can see you are honest clear through.”
  10. ‘Quality’ is just conformance to requirements. You get the behavior you critique for, so set your standards and then require conformance to them. Quality will come from that effort, not from slogans, posters, or even threats.
  11. Learn from the mistakes of others. You can’t live long enough to make them all yourself.
  12. Set S.M.A.R.T. Goals. Goals you set for yourself, or others, should be Specific, Measurable, Achieveable, Realistic, and Time-based.
  13. Set an example. “One of the most significant parts of a manger’s job is for them to become a positive role model that can pull a team together and deliver the level of service expected from their customers.”
  14. Know Your GPM. In engineering, gpm is gallons per minute, a design criterion. In Management GPM is an acronym for Goals, Plans, and Metrics. To achieve your goals, you must first determine what your Goals are. Then you have to develop a Plan that gets you to your goal. Finally you need Metrics (measurements) to know if you are moving toward your goal according to your plan.
  15. Train Your Supervisors. The key to your business success is the productivity of your employees. The key to employee productivity is their perception of their immediate supervisor. Invest in training your supervisors and managers. It will pay off.
  16. You Can’t Listen With Your Mouth Open. Your associates, your employees, your suppliers, your customers all have something of value in what they have to say. Listen to the people around you. You will never learn what it is if you drown them out by talking all the time. Remember, the only thing that can come out of your mouth is something you already know. Shut up and learn.
  17. Practice what you preach. To lead, you have to lead by example. Don’t expect your people to work unpaid overtime if you leave early every day. Don’t book youself into a four star hotel on business trips and expect your employees to stay in the motel off the freeway.
  18. Leaders create change. If you lead, you will cause changes. Be prepared for them and their impact on people within, and outside, your group. If you are not making changes, you are not leading.
  19. Don’t Limit Yourself. The difference between leaders and managers is that leaders do not set limits on themselves. There are enough people trying to limit what you can do. Don’t be one of them.
  20. Anyone can steer the ship in calm waters. What will set you apart in your career is how you perform during the tough times. Don’t become complacent and relax just because things are going well. Plan ahead for the downturn.
  21. You have to make a difference. The group you manage has to be more effective, more productive with you there than they would be if you were not. If they are as productive without you, there is no business sense in keeping you on the payroll.

Source: http://management.about.com/cs/generalmanagement/a/mgt_tips03.htm


Scope – The fourth element (and most important) to manage

October 22, 2008

A successful Project Manager must simultaneously manage the four basic elements of a project: resources, time, money, and most importantly, scope. All these elements are interrelated. Each must be managed effectively. All must be managed together if the project, and the project manager, is to be a success.

  • Resources
    People, equipment, material
  • Time
    Task durations, dependencies, critical path
  • Money
    Costs, contingencies, profit
  • Scope
    Project size, goals, requirements

Most literature on project management speaks of the need to manage and balance three elements: people, time, and money. However, the fourth element is the most important and it is the first and last task for a successful project manager. First and foremost you have to manage the project scope.

The project scope is the definition of what the project is supposed to accomplish and the budget (of time and money) that has been created to achieve these objectives. It is absolutely imperative that any change to the scope of the project have a matching change in budget, either time or resources. If the project scope is to build a building to house three widgets with a budget of $100,000 the project manager is expected to do that. However, if the scope is changed to a building for four widgets, the project manager must obtain an appropriate change in budgeted resources. If the budget is not adjusted, the smart project manager will avoid the change in scope.

Usually, scope changes occur in the form of “scope creep”. Scope creep is the piling up of small changes that by themselves are manageable, but in agregate are significant. For example, the project callls for a building to be 80,000 square feet in size. The client wants to add a ten foot long, 4 foot wide awning over one bay door. That’s a pretty minor change. Later the client wants to extend the awing 8 feet to cover the adjacent bay. Another minor change. Then it’s a change to block the upwind side to the covered area to keep out the wind. Later, it’s a request to block the other end to make the addition more symetrical. Eventually, the client asks for a ceiling under the awning, lights in the ceiling, electrical outlets, a water faucet for the workers, some sound-proofing, and a security camera. By now, the minor change has become a major addition. Make sure any requested change, no matter how small, is accompanied by approval for a change in budget or schedule or both.

You can not effectively manage the resources, time and money in a project unless you actively manage the project scope.

When you have the project scope clearly identified and associated to the timeline and budget, you can begin to manage the project resources. These include the people, equipment, and material needed to complete the project.

Source: http://management.about.com/cs/projectmanagement/a/PM101c.htm


I’m Google I can read Flash

October 22, 2008

In a recent announcement, Google and Adobe have teamed up to develop a new algorithm for the spider bots to index text content in Flash file.

It also extracts URLs and understand simple JavaScript like SWFObject. This was not a partnership for the gain of Google, but also for Adobe. With this new research, Adobe has founded formats in which Flash sites will be created, constructed and designed to therefore be optimised on the Google.

However people have been questioning as to how much does the Googlebot actual index? Will it take all part of the text content? Will it rank flash files (if multiple were found on a page).

Beussery.com has been doing some extensive research which can be found here http://www.beussery.com/blog/index.php/2008/10/google-flash-seo/

If you can read that code lingo and various scenarios then knock yourself out. I just read the first paragraph to get an idea, and avoided collapsing on my keyboard.

Source: http://www.vickylalwani.com/2008/10/16/i-am-google-i-can-read-flash/


The Top 10 Tips for Project Quality Assurance (Project QA)

October 20, 2008

1 Document Your Policies
You should ensure that you document policies for your project – remember that it can be difficult to implement quality if there isn’t a shared understanding across your project of what you are seeking to achieve. For example, see the QA Focus policies on Web standards and link checking.

2 Ensure Your Technical Infrastructure Is Capable Of Implementing Your Policies
You should ensure that your technical infrastucture which is capable of implementing your policies. For example, if you wish to make use of XHTML on your Web site you are unlikely to be able to achieve this if you are using Microsoft Word as your authoring tool.

3 Ensure That You Have The Resources Necessary To Implement Your Policies
You should ensure that you have the resources needed to implement your policies. This can include technical expertise, investment in software and hardware, investment in training and staff development, etc.

4 Implement Systematic Checking Procedures To Ensure Your Policies Are Being Implemented
Without systematic checking procedures there is a danger that your policies are not implemented in practice. For example, see the QA Focus checking procedures for Web standards and link checking.

5 Keep Audit Trails
Provide audit trails to record results of checking procedures. This can help spot trends which may indicate procedural failures (for example, a sudden growth in the numbers of non-compliant HTML resources may be due to deployment of a new authoring tool or inadequate training for new members of the project team).

6 Learn From Others
Rather than seeking to develop quality assurance policies and procedures from scratch you should seek to learn from others. You may find that the QA Focus case studies provide useful advice which you can learn from.

7 Share Your Experiences
If you are in the position of having deployed effective quality assurance procedures it can be helpful for the wider community if you share your approaches. For example, consider writing a QA Focus case study.

8 Seek ‘Fitness For Purpose’ – Not Perfection
You should seek to implement ‘fitness for purpose’ which is based on the levels of funding available and the expertise and resources you have available. Note that perfection is not necessarily a useful goal to aim for – indeed, there is a danger that ‘seeking the best may drive out the good’.

9 Remember That QA Is For You To Implement
Although the QA Focus Web site provides a wide range of resources which can help you to ensure that your project deliverables are interoperable and widely accessible you should remember that you will need to implement quality assurance within your project.

10 Seek To Deploy QA Procedures More Extensively
Rather than seeking to implement quality assurance across your project, it can be beneficial if quality assurance is implemented at a higher level, such as within you department or organisation. If you have an interest in more widespread deployment of quality assurance, you should read about the ISO 9000 QA standards.


Project Management Best Practices – Basics and useful ideas from experienced Project Managers

October 1, 2008

Project Management Best Practices – Define Your Project Well

Project – work that is not normally done [what we normally do is operations, not a project]. A project will have to meet four criteria-

  1. Temporary – it has a beginning and an end; so its project team will only exist for the purpose of that project
  2. Unique – the outcome is one of a kind. However, projects might well be similar, so planning will consider what others have accomplished that is similar, and the way those other projects might have elements that are the same or different. And a SWOT Analysis will consider whether these similarities and differences are Strengths or Weaknesses.
  3. A Creation – because you are creating something that did not previously exist, you are probably going to go through phases of development, and there will be many people and even other organizations who have a stake in the outcome. Communicating the project’s status and progress through the phases will be important.
  4. A Product [or Service] – is the goal of the project. You measure the project’s value by how it met the goal of producing the product or service.

Now, with the basics out of the way, let’s look at some project management best practices.

Project Management Best Practices – Apply to Any Type of Project Activity

The obvious types of projects come to mind – huge civil engineering projects like bridges and power dams; construction of residential and commercial properties; implementing or upgrading computer systems.

But project management best practices and techniques can and should be applied to any activity that meets project definition:

  • the annual marketing plan;
  • all of the corporate budgets;
  • developing or upgrading human resources manuals and policies -
  • designing and installing a new CRM (customer relations management) system
  • starting online business
  • overhauling your bid-response system
  • preparing for the annual audit
  • virtually every consulting engagement whether you are hiring the consultant or are the consultant

- you get the picture.

Look again at the definition of project above, and if your activity meets the criteria, use the project management best practices.

Project KickStart is a project management program for planning everyday work projects. Especially suited for small- to mid-sized projects. Project KickStart can be used stand-alone or in conjunction with Microsoft Office and ACT!

Project Management Best Practices – Don’t Cut Short on the Planning Phase

Fast-Tracking, Rapid Application Deployment, Rapid Deployment and many other euphemisms started appearing on the project management scene a few years ago. One can’t really argue with their objective – speed up projects and therefore reduce cost.

Those cases where the goal was accomplished have our respect and admiration…but they are few and far between. Why?

Fast tracking is usually accomplished by gutting the planning process. Sure, if you shorten the time here, you are underway faster. But let’s look at some components of a good planning phase and see if they can safely be dispensed with…

Scope

  • define
  • target audience, customer, recipient
  • why the project is needed

Stakeholders

  • individuals and organizations who need the project or are affected by it

Standards

  • what quality level is required: perfect, workable, just get it running?
  • whose standards: internal policy, external like government or regulators? written or implied?

Constraints

  • key people or resources not available
  • deadlines

Organization Structure

  • authority: project manager often gets as much authroity as s/he takes
  • autonomy: team members need approvals from their respective organizations?
  • stakeholders: are there others who think they should be stakeholders but haven’t been included?
  • goals: does the whole organization agree with the goals?

Risks [Obstacles]

  • has a SWOT Analysis been done?
  • what steps have been identified to overcome the risks?

Goals

  • should be written, clear and detailed
  • need to be signed off by all stakeholders before execution commences to avoid later confusion

Can any of these steps be left out? We don’t think so!

Speeded up? Sure…as long as it is not accomplished by glossing over them. For example, a SWOT Analysis is often done casually by a small section of the project team…and the result is that only some of the threats are identified. The key is to keep each step to a perspective that is appropriate for the overall project. The extent of risks to consider can be different for a trial launch type of project than for one that demands virtual perfection.

Project Management Best Practices – Hints and Tips

General

  • You can have goodYou can have fastYou can have cheapBut you’re not likely to get all three, so Pick the Two that are most important to this project!
  • Define project correctly, and do a Postmortem at each major milestone and after completion

Planning

  • Without a plan, your project will be impossible to control
  • People who must execute a plan should be involved in its preparation
  • Use a Project Notebook to fully document a project
  • Project plan should be signed off by all stakeholders in a meeting. Use a Change Order form, signed by affected stakeholders, to record significant changes to the project.
  • BEWARE SCOPE CREEP!
  • Mission statement should be developed for larger projects before goals and objectives are established.
  • Satisfying the customer(s) of a project must be a primary concern.
  • Objectives should be written out and placed in project notebook.
  • Objectives should contain actual calendar deadlines rather than being specified as “within x months”

Estimating Time and Cost

  • Padding is legitimate to reduce risk, but should be done above the board
  • An estimate is not a fact
  • Reduce time available for a person to work on a project to allow for meetings, breaks and other interruptions
  • Use chart-of-accounts to track labor costs.
  • Record time daily to ensure accuracy.
  • Gantt chart is most useful to see who is responsible for which tasks.

Scheduling

  • Scheduling considers both duration of tasks and sequences in which work must be done.
  • Break work down only to level needed to develop an estimate sufficiently accurate for intended use.Don’t plan in more detail than you can manage.
  • Bar chart = Gantt ChartBar charts do not usually show interrelationships of work, thus do not permit easy analysis of impact on a project if one activity slips
  • Software can show how vacations and holidays will extend working times in order to assess their impact

Organization

  • You must consider your own Organization Structure when planning and staffing your project.Hierarchical structure has serious disadvantages for running multi-discipline projects.Matrix is almost synonymous with project management because of its advantage in dealing with many disciplines.Success in matrix requires very good interpersonal skills on the part of all managers

Project Manager

  • Look for a leader, not just a manager. People skills are important.
  • Negotiating skills and flexibility will be important attributes. No project ever goes exactly according to plan and the PM has to negotiate the adjustments.
  • Problems “go with the territory” and must be resolved. Avoiding conflict and technical problems only lets them fester and build.
  • Communication skills are critical. PM will often have to bridge a gap between technical and non-technical stakeholders. And credibility is always at stake.
  • PM really has to be “everybody’s friend…and nobody’s friend” in order to lead the project to the desired conclusion.

Project Management Best Practices – Decide Early Where You Will ManageTime, Costs and Budgets

One of the most significant project management best practices revolves around the fact that most projects involve non-financial and financial factors.

Non-financial Information

Non-financial includes things like defining tasks, and their sequence and duration; scheduling; resource planning for people and equipment; organizational planning; risk identification; quality planning; staffing; reporting; problem-solving; controlling changes.

Financial Information

But projects also have financial factors: they generally have a finite cost limitation so estimates and budgets and cost control are needed.

To the extent that the Project Manager has to interact with other sections of the organization and even outside agencies for resources, they become stakeholders in the project, but the manger is relatively independent in managing and reporting on their use – they come under his control for the duration of the project.

However, with financial factors, it is a certainty that the project manger will have to interact somehow with the financial or accounting function. Eventually all financial information finds its way into the general ledger and the financial statements of the organization. So project management best practices recognize and deal with this inevitability right up front.

It amazes us how often a project plan does not recognize that the finance / accounting function is inevitably a stakeholder of every project that has cost / budget constraints – and what project doesn’t have those constraints?!

Financial Information Model

Your organization might not fit this model exactly, but here is a general model to help you visualize the different ways financial information can be collected and flow through your system.

Time sheets for people might be entered into a specialized time and billing or project accounting module; or into a payroll subsidiary ledger. Costs of equipment and expenses might be entered into the time and billing module or accounts payable subsidiary ledger.

Both time and expenses might go in through a job-costing module.

In some older and inflexible systems, entry might be right into the general ledger module.

Also, your organization should have a system of internal control to ensure that information flows smoothly and accurately between the components of the model.

Notice that this has become complex already – and we have only considered what might happen given the existing systems that could be in place in your organization.

There are so many possibilities…

and your project manager has to work with whatever system your financial function has in place…

One of the first project management best practices is that the Project Manager needs to consider the financial function as a stakeholder and get briefed as to how the existing system works.

This briefing must include the reports that can be made available to the Project Manager and the timing for the processing cycles that the financial function uses to process information.

In general, newer systems process transactions more frequently and closer to real-time, while older systems have less frequent cycles such as weekly, biweekly or even monthly. While a Project Manager probably doesn’t need up-to-the-second information, he also probably can’t control his project with just monthly information either.

In general, newer systems have better reporting available, while older systems have less flexible or extensive information. Also, newer systems can often obtain or produce specialized information quite easily through report writers whereas older systems don’t have that flexibility.

Armed with this knowledge, the project manger can now deal with one of the most important and basic of the project management best practices – deciding where to manage time, costs and budgets.

Other things being equal, if the existing financial system can provide the information, it is going to be much simpler to rely on that than to maintain another whole system. Conversely, if the existing system is not capable, then he has to look to alternatives. Either way, making this decision early leave more time to prepare for whatever approach is selected.

Remember that whether you choose or are forced to go outside the financial system for part or all of your project management information, you still have to have enough controls and reconciliation to ensure the integrity of the data you are using. Costs in your project system must be the same as costs in the general ledger.

Source: http://www.family-business-experts.com/project-management-best-practices.html


Product management vs. Project management

September 30, 2008

If you want to be a bad product manager, confuse product management with project management. The words are so close because the two concepts are so similar. Product managers should manage projects since they need to ensure that the projects get done. They’re both management roles (right?) so the skills and experience are virtually the same. Project managers just get in the way and try to take control of the project away from the product manager.

If you want to be a good product manager, learn the difference between product management and project management. Despite the similar names, there are big differences between product management and project management. Confusing them is common, even among those experienced in product development.

Project managers are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. As they relate to products, projects can be undertaken to build a product, to add new features to a product, or create new versions or extensions of a product. When the project is complete, the project manager will usually move move to a new project, which may be related to a different product.

Product managers are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle. Other projects related to the product may be initiated, with the product manager being the one constant stream throughout, defining the project goals and guiding the team to accomplish the business objectives that have been defined.

One challenge of the two roles is that they can appear to be at odds with each other. A product manager may want to add a lot of features to meet observed customer needs, but the project manager may want to keep scope as small as possible so that the project is delivered on time and under budget. Traditional definitions (and probably those above, too) often mischaracterize the project manager as singularly focused on getting the project finished on time and under budget without any concern as to whether it meets the market or customer needs.

Good product managers and good project managers are able to create a balance of these conflicts. Good project managers know that the true success of a project is not whether it is on time and within budget, but whether it meets the defined goals and objectives. Good product managers know that all the features in the world will not matter if the project is continually delayed and never makes it to market or if it is too over budget to be completed.

Especially for web-based and technology products, the confusion between project and product management is common and potentially harmful to organizations who do not acknowledge the distinction. As Rob Grady writes in Are you a Web Project Manager or Web Product Manager? (Part I):

Today, as websites have become increasingly important in business, they are, unfortunately, still being managed as projects. This becomes a problem in meeting defined business objectives, prioritizing, having the right skills to manage what has now become a core business function. If the website has become or is a core business function there is a greater need than managing a project, it has become a product which will have a series of projects driven through business objectives.

There are some important points to keep in mind related to project management and product management:

  • Just like every product needs a product manager, every project needs a project manager.
  • Just because product managers think they can manage their own projects does not mean they should.
  • The skills, talents, and traits involved in project management are very different from those involved in product management.
  • Just like it is hard to find one single person who can fill the product management role and the product marketing role, it is hard to find one person who can be successful at both the product management and the project management role.
  • Project management is not a stepping stone to product management, nor vice versa.
  • Good project managers are just as valuable as good product managers.
  • Finding a good project manager to manage your projects will help you be an even better product manager.
  • The less time product managers spend on project management, the more time they will be able to spend on product management.
  • To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.

Source: http://www.goodproductmanager.com/2007/09/24/product-management-vs-project-management/


MITOpenCourseWare – Free online course material from MIT (Massachusetts Institute of Technology)

September 26, 2008

This is a very nice initiative from MIT that publicates free online course material to anyone.

Learn is always good, and for free IS AWESOME!

Read the official about text bellow:

Unlocking Knowledge, Empowering Minds.

Free lecture notes, exams, and videos from MIT. No registration required.

MIT OpenCourseWare (OCW) is a web-based publication of virtually all MIT course content. OCW is open and available to the world and is a permanent MIT activity.

What is MIT OpenCourseWare?
MIT OpenCourseWare is a free publication of MIT course materials that reflects almost all the undergraduate and graduate subjects taught at MIT.

  • OCW is not an MIT education.
  • OCW does not grant degrees or certificates.
  • OCW does not provide access to MIT faculty.
  • Materials may not reflect entire content of the course.

How do I register to use MIT OpenCourseWare?
There is no registration or enrollment process because OCW is not a credit-bearing or degree-granting initiative.

Can I get a certificate?
No. MIT OpenCourseWare is a publication of the course materials that support the dynamic classroom interactions of an MIT education; it is not a degree-granting or credit-bearing initiative. However, you should work through the materials at your own pace, and in whatever manner you desire.

How do I find what courses are available? How do I search your site?
A site overview is available for MIT OpenCourseWare. You can also browse courses by department or use the advanced search to locate a specific course or topic.

High school students and educators should check out Highlights for High School.

What it takes to support this work

Each course we publish requires an investment of $10,000 to $15,000 to compile course materials from faculty, ensure proper licensing for open sharing, and format materials for global distribution. Courses with video content cost about twice as much, but your feedback about the significant value of these video materials helps to justify the cost. Learn more.

CHECK IT OUT: http://ocw.mit.edu/OcwWeb/web/about/about/index.htm