90 Percent

Project management, productivity, change management, and more!


Leave a comment

Need help with a tight schedule? – Part 2

In part 1 of the article, we’ve explored two typical ways to speed up projects and a few alternatives that can also help. Here are a few more alternatives:

Reduce stakeholder delays or revisions for feedback

As the project progress, it is a standard practice for some types of projects to have different kinds of deliveries sent to stakeholders to receive their feedback or their approval before moving forward to the next phase.

When the schedule is tight, you might be able to negotiate fewer rounds of revisions allowed or shorter delays to approve some documents.

Foe example:

  • Maybe typically the stakeholders have 5 days to provide consolidated feedback to your team. In case of a tight deadline, you might be able to negotiate 3 days instead;
  • If 3 rounds of feedback are allowed per delivery, maybe it can be reduced to 2, even 1.

Pros:

  • Faster approvals or less revisions means the schedule is shorten.

Cons:

  • This can add risk that stakeholders cannot meet their deadlines given and this might cause some phases to be late;
  • If rounds of revisions are removed, there is also some added risk that they find some issues later on, which you will not necessary be able to negotiate more budget or schedule since they can debate they should have had an additional revision normally.

Combine two deliveries together

This obviously applies to only a few types, but in some cases it’s possible to combien two deliveries into one, this can reduce back & forth and accelerate the project.

For example:

  • A wireframe delivery can be combined with the design phase. The final output are layouts (wireframes are implied within). Both are basically done in parallel with designers & UX designers working together. In this case, stakeholders would approved the user interface at the same time as the design work;
  • Simple website pages that derive from approve pages can be delivered only once developed, without any prior wireframe or design work. All this work is implied inside the develoed pages themselves for the stakeholders to approve.

Pros:

  • Be combining (or removing) deliveries, hence removing approval phases because of the reduced quantity of deliveries, this shortens a schedule quite a lot.

Cons:

  • This adds risk of rework since stakeholders see more of the work accomplished at the same time, therefore can have feedback on more elemets, thus creating more rework. In our example above with layouts, if the user interface itself doesn’t please stakeholders and must be revised, this means the layouts must be revised accordingly as well.

Roll stakeholder feedback into the subsequent phase and/or deliverable

This technique can only be applied to certain types of projects, and also depends of actual feedback. Basically, instead of going through one additionnal round of feedback where you send the revised delivery and wait for feedback, you skip on to the next phase and send the revised work fused with another delivery.

For example:

  • The feedback given on the latest copy sent is that several terminology must be changed and they ask that your team proposes new copy. You could send a revised copydeck, wait for approval, then start integrating the copy inside the project, whether it’s a website, a flyer, a software, etc. Or, you could propose new copy that you integrate right away and the stakeholders can vet it directly within staging or inside layouts (a.k.a. the next delivery).

Pros:

  • This can remove one revision’s delay therefore saving time in the project’s budget;
  • Sometimes this can also help stakeholder approves certain elements (like copy) inside a different context, helping them understand.

Cons:

  • This can add risk of rework if the revised work done according to the feedback received is still not approved. In order to mitigate this, it’s ideal to use this technique when the feedback is fairly straightforward.

Putting case issues aside or reduce the “pixel perfect” expectations

In IT projects, running into issues with a particular OS or browser that affects only a few people is quite recurrant. When these issues are found, it doesn’t mean it’s worth spending time to fix those issues.

For example:

  • Older versions of Internet Explorer show the form 2 pixels more to the left than it should; this is barely visible to anyone and older versions of IE may be used only by a small percentage of visitors;
  • If a user does 4 specific steps to reproduce the issue, only to have a blank space added to his menu until he refreshes the screen; this is not a showstopper, nor does it happen often that a user reproduces it.

Pros:

  • You can save a lot of time trying to find solutions to issues that may never be seen by anyone or will not bother many (if any);
  • You can also reduce costs that way, which is an added perk.

Cons:

  • You still risk users hitting issues and potentially complaining about it; even if the probability is low, you still reduce the quality of the work by using this technique.

Use senior resources

Depending of available resources, some more senior resources might be able to do the work quicker. This allows you to keep the same team size, but still shortened the schedule. It doesn’t necessarily mean it needs to be a senior resource, but basically anyone who can get the work done faster.

For example:

  • One of the resource in the agency is known to be fast but has very little experience with very complex development. He could very well take care of your project that is considered simple, and he’ll be able to do it faster than others;
  • A junior resource on your project thinks he can tackle a task in 35h, but another more senior colleague knows he can tackle it in about 15h;
  • Also, note that senior resources then to provide better quality work, meaning you will most likely also save time long-term by avoiding lots of issues being found in your QA cycle.

Pros:

  • Tasks are done faster by more reliable resources, this can have a positive impact on your schedule since chances are, things will run more smoothly.

Cons:

  • These senior resources may not be available for your project since they are already used on other more important projects;
  • These resources tend to cost more, although they should take less time.

 

I hope these tips can help you when you are stuck in a tight spot with deadlines, do not hesitate to send more ideas below!


Leave a comment

Need help with a tight schedule? – Part 1

Source: dhester

Source: dhester

One of the main concerns for project managers  is delivering the project on time. More often than we would love to admit, this can be hard, and a variety of reasons explain why it can be a challenge (events, client expectations, business need, etc.).

Either while we’re planning the initial schedule, or as the project evolves, there are many different ways to help shortened a schedule so you can deliver your project on time.

In the past, I’ve written an article that listed a few tips to help you out, here is complementary information and more alternatives:

The two typical tools that can applied to all projects are the following:

Fast Tracking

Fast Tracking consists of starting a phase of a project sooner, overlapping with the previous phase.

For example:

  • If design is only partly approve, development could start earlier with what is approved;
  • If only parts of the projects are developed, QA can start for those pieces instead of waiting for the very end of development. This could be considered more of an agile approach.

Pros:

  • The duration that the 2 phases overlap is the duration removed from your overall schedule.

Cons:

  • The more you fast track, the more risk you add to the project. For example, unapproved design parts that are being finished might have an impact on what was approved, and if development was started, there is a risk of rework. If you decide to fast track even more and develop before any design is approved, you add risk of rework if the client approves only parts of it (or none of it!).

Crashing

Crashing is adding more resources to tasks so their duration is reduced. If you are working with external resources, it could also mean paying more to have a deliverable done faster.

For example:

  • If a website requires 240h of back-end development, and was planned with 2 resources for  3 weeks; you could add a third developer;
  • Overtime.
  • Third-party is developing the website you designed, they will deliver 2 weeks sooner, but at a cost.

Pros:

  • Tasks will get done faster, meaning the project’s duration can be reduced.

Cons:

  • Adding more resources can be costly, meaning the budget will take a hit. In our example above, separating 200h of work between 2 developers does not necessarily mean 100h each, just like you will not get your website done in 1 hour with 240 developers. There is added management time to communicate information to more people, there is also overhead between these people so they can communicate who does what, and if whatever they are working on is linked to one another, one’s code affect the other’s;
  • Too much overtime will tire the team, and if abused, might have worst consequences like team members leaving or left unmotivated to go on.

There are also  several other ideas that can be applied to some types of projects:

Separate project into different phases

Applicable for many types of projects, its scope can be separated into more than one delivery until the project’s completion.

For example:

  • If a software is due in 2 months since a conference is being held shortly after, only part of the software might be realistic to be delivered. You can decide to include fewer features for example, planning to roll-out updates in the subsequent weeks;
  • If a massive social campaign is starting on a certain date and you have an absurd quantity of posts to create, they do not need to be all created for the launch of the campaign. A first batch could be ready for the launch, and while those are being shared with the community, a second batch can be done, and so on.

Pros:

  • Allows the on time delivery of what is realistic. This can give an enormous amount of flexibility with a project that has an unrealistic deadline, or a typical client expectation to get a project out the door as soon as possible.

Cons:

  • This can add costs to your project. If a website is going live with half its pages, and you plan updates every week to add more pages, this creates the need for more deployments, which adds costs;
  • This may not fully satisfy your stakeholder(s), so it is important to manage this expectation as early as possible, ideally at the very beginning.

Reduce scope

A scope might be defined by stakeholders’ requests, or might be defined by what the team thinks is ideal for the project’s success. However, sometimes, there is just not enough time to do everything, and splitting the project might just not work. In these cases, reducing the scope might be your best bet.

For example:

  • A client asks a contest in time for summer, and they have enough budget to do something “cool” where users play a mini game to enter the contest. Unfortunately, they have decided to go forward with this last-minute, leaving very little time before the deadline. This might be a case where even if budget permits it, the idea of the contest might need to be reduced to something simpler like a simple contest where users fill a form.

Pros:

  • Less work means the project can be done faster.

Cons:

  • The client might not be fully satisfied with the reduced scope;
  • The grade of the project is diminished since it wasn’t built as it originally should and might not satisfy objectives as much as it could have been.
  • This removed work will also reduce the budget, meaning the organization will benefit less from this project.

Stay tuned for part 2.


Leave a comment

5 tips to give great project briefs

Briefing your team on the new project is a very important step and one that will give your team a good/bad first  impression on how things are going to go until the closure of the project.

Recently, I wrote about a few examples on how to give a very bad first impression ( and headaches) by giving very bad project briefs, now let’s concentrate on how great ones are given:

1. Think of it as a story

A colleague of mine gave me this great tip and I couldn’t agree more! A story is built so that anyone can jump in and understand what is going on by reading it; the same should apply to your project brief.

Setting

Describe the context of the project so that anyone can understand what they will be working with. In other words, describe  the current situation and summarize why things are as they are.

For example: a website has been build 8 years ago, back when  responsive design did not exist, and no CMS could be afforded. Today technology has evolved and CMS are more affordable with open-source platforms.

Conflict

What is the issue or what causes this project to exist all of a sudden? If we use our website example, then the issue could be that the website is not mobile friendly and the client cannot make any simple modifications without the need for a developer.

This creates the need, and gives birth to the project just like it would with a story.

Plot

Explain what will happen so that the project can be completed. In other words, list deliverables and what’s expected for each. For example: the team will deliver a concept idea for a new contest, than layouts of the contest, and then the team will develop it.

Characters

Talk about all stakeholders (team, client, third-parties, etc.) and everyone does.

2. List clear, measurable objectives

The objective of the project will guide the team towards the right path. If one of the objectives is to “create brand awareness” then the social media campaign they build will differ from a campaign that used to gather emails to send future promotions.

Make sure the objectives are measurable, if they are not, then they will be open to interpretation and you will not be able to assess properly if they are met or not. A good example of measurable would be “Gather 5000 new fans on the Facebook page” versus “Gather new fans…”.

3. Make sure it’s clear who does what

Here you want to make sure to explain what the team will be doing; is it a website? social media campaign? Mobile app? Is it more than one thing?

Within this, list what needs to be done is not implied/guessed; list it clearly.

Keep in mind that third-parties or clients are also stakeholders that have responsibilities within the project and listing their responsibilities is important to the team; both to make them understand the full context and also to know who to talk to during the project.

4. Answer all questions

The team will ask questions when they are briefed, that’s practically inevitable; you have to make sure all questions are answered. If you cannot answer right away, list all questions  so that you can speak to who you have to in order to get the answers as quick as possible.

If you do not answer your team’s questions, how can you expect them to deliver what is needed?

5. Keep it simple to read

Just like every document you create, if it’s too long and hard to read and nobody uses it, then even if all important information is available, the goal of the document will be skipped. Makes sure it’s well formated including proper titles, use lists, you can even highlight key information, and keep sentences as short as possible.

In conclusion

How a project starts gives a good idea of how the project itself will be throughout it’s life-cycle which is why it’s important to give good project briefs so that the team can be confident the project will go well. This will not only make sure they know what they are expected to do, but also it will motivate them to deliver.

 

If you have more tips, don’t hesitate to share below!


Leave a comment

5 tips to help control your project’s budget

Controling your project’s budget can be challenging; there are many obstacles that can lower your budget’s health but there are many tactics you can use to keep it healthy.

Here a are a few tips to help:

1. Reduce scope

As simple as this may sound, we may be so focused on the client’s requests that considering to reduce scope skips our mind. However, often the scope includes lots of “nice to haves”, which means that your project could be just as successful without a few of the requested features .

By identifying and removing those “nice to haves”, you can reduce costs and focus on what’s really necessary.

2. Leverage past work

Leveraging work from other projects can save a lot of time in a new project. This is often an overlooked strategy and for 2 main reasons:

  1. Lack of visibility of what’s been done: We cannot be aware of everything that is available within an agency. Therefore, there may some parts of past projects that could be re-used that you are not aware of.In order to help with that, communicate with your colleagues, or search through the agency’s archives.
  2. Lack of actual available materials: Not everything that is created is made with flexibility in mind. This means that the chances you can re-use most elements can be very low. Creating something that is re-usable generally takes more time initially, and people will often use the faster path due to tight deadlines or simple lack of time. This approach is good for short term, but on the long term you can leverage less work.

3. Use experienced resources

Resources with more experience are bound to cost more, however, they will execute the work in less time. Furthermore, they will require less effort to manage them. All of this will save

Be mindful that depending of the work, experienced resources may not be motivated and render them less cost-effective; make sure it is interesting or challenging enough for them.

4. Reduce meetings

This one can be tough since people like to set meetings. They give the illusion of being productive when in reality they are known for the exact opposite; unproductive, and often useless. If you have regular status meetings with your team, consider reducing the amount and fill the gap with a few quick emails or maybe even just making sure whatever PM tool you use is updated properly and you can simply have a look.

If you do some quick math, imagine a weekly 1h meeting with your team consisting of 10 members. This goes on throughout your 6 month project. That’s 260h hours spent in meetings. Opinions vary but meetings are often up to 80-90% inefficient, this means that around 200h are potentially wasted on your project.

5. Use a smaller team

Smaller teams cost less and they are easier to manage. Furthermore, if no two people share the same role, than there is no need to spend additional time to make sure the team members do not overlap their work.

In order to be able to have a small team, this requires a realistic schedule that enables the team to work with a smaller velocity.


2 Comments

4 tips to be diplomatic in tough conversations

Often you will be faced to tell someone something he may not want to hear, whether it’s a bad news, giving an answer to a question that you know will not please, or maybe it’s a last-minute request.

Regardless, there are many different ways to communicate this, some of which are more efficient than others. Here are some tips to help you deliver a message the right way:

1. Watch your facial expression and body language

One thing that can speak louder than words is your body language , so be careful how you look when you have something “tricky” to say or ask.

For example, avoid having a smile when you are announcing a bad news to someone; it may be because you are nervous, but you still need to be careful because it can greatly offend who you are talking to.

There are many things to consider when thinking about body language which will not be covered in this article, but a quick research on the web and you’ll easily find plenty of tips 🙂

2. Do not beat around the bush but balance it

If you have something to say, say it in a reasonnably short amount of time.  If you talk, and talk, and talk, and never get to the point, the person you are talking to may get irritated, more worried, or worst, and will be less likely to be open-minded about what you are going to say.

Do be careful and balance how you handle this; a short introduction or a small “Sorry but…” never hurts, if you cut everything to the bone and drop the bomb, you may also come as too abrupt.

3. Explain why

Receiving a bad news or a last-minute request is never really fun, but not knowing why it has to be that way can be even worst; take the time to explain the context and answer questions, this will help motivate or attenuate any negative feelings.

4. Listen, and care for the response

Most likely the person will want to explain/justify or even ventilate; whatever it is, part of being diplomatic is not only how you share the information but also how you are overall inside the conversation. If you do not care about what the person replies, or if you listen but give no follow-up answer, it will frustrate the other even more.

In conclusion

Diplomacy is very important and will help you in all the communication you are involved in. Take this seriously and the result may surprise you!


Leave a comment

Are you a micromanager?

Micromanagement is a management style whereby a manager closely observes or controls the work of subordinates or employees. Micromanagement generally has a negative connotation.
Source: Wikipedia

Micromanagement often brings frustration, discomfort, and overall less efficiency within a team. It is something I strongly advise against doing, and hopefully this article can help you be aware if you have micromanagement tendencies, or even spot some of your colleagues.

Signs of a micromanager

Here below are but a few of the signs that can help you identify micromanagement:

Need to control everything
One of the top signs of micromanagement is the obsessive need to know/control everything. You feel like you need to be omnipresent and whatever details you are missing are considered failure or unacceptable.

This results in asking too many status reports from the team, constantly calling/emailing them for an update, and having no regards to disturbing people to find out whatever you think you need to know.

Behind your shoulder
When expecting a certain delivery and the due date is close, you may notice some people literally standing behind the person working, and simply waiting for that person to finish, even if it was clearly communicated that more than 5-10 minutes are needed.

Not only does this person annoy his colleague and frustrates him, but while he just stands there waiting, he is not doing anything productive and wasting precious time.

Poor delegation
Someone who needs to control everything will have a tendency to keep the work to himself since it’s easier to control and make sure it’s one ‘his way’. However, when he does delegate, he will dictate exactly how to do it, and if the colleague takes any liberty outside the directions, than the micromanager will tell him to adjust the work or take it back and adjust himself.

Why?

Lack of trust
If the micromanager does not trust the people he works with, either because it is justified or because he thinks he is superior to everyone, than the lack of trust it brings will make him act the way he does.

Because of another micromanager
Sometimes, thee micromanager is actually the one pulling the strings behind, and someone else if doing the micromanagement.

The micromanager hides in plain sight while having someone else take the fall. This can be a very uncomfortable position for the person stuck doing the work. I speak from experience here, believe me!

Obsessive need to control
Some people just have his need to control everything, regardless of what’s going on and with whom they are working. If they don’t control everything, they feel they are not doing their job correctly.

Few tips…

There are a few habits that you can develop that can help you with a micromanager:
Reports: Since they need to feel in control all the time, they feel the need to know everything that is going on, therefore, sending regular status reports (more than you normally would) or constantly adding him in ‘cc’ on mails will satisfy that need, and avoid having him over your shoulder to find out what’s happening.

Stick to your commitments: If you stick to your commitments, from delivering work to status reports on time, this will make you reliable to the micromanager, and the added trust this will give him will diminish his need to control you.

Surround yourself with great people: If you feel you are guilty about not trusting the people you work with, and assuming it’s justified, than it’s time you make a change and surround yourself with a team that delivers and you may find your micromanagement days going away.

Talk to him: This depends on the role you have versus the micromanager’s role, but talking one on one may help clarify a lot of things. Communication is the key, right? You may find out why he is acting that way, or you may make him aware of his behavior; you never know until you have a real open conversation.

In conclusion

Micromanagement is a type of management that needs to be avoided, whether you are guilty of it, or a colleague is, do your best to fix it.

Have you ever worked with a micromanager? Share your story!


Leave a comment

How to give bad project briefs

Briefing the team to start a project is an important step contributing to the project’s success. How the brief is handled can be very indicative of how the project will
go.

However, even if it is very important, some remain unaware of the impact it has on the team to have an unacceptable project brief.

Here are below a few examples of bad project briefs. If you are guilty of anything similar to this, please review how you brief your team, I know you can do better than this. 🙂

1. The “Pass-by” brief

Situation:

  • You happen to pass by the person you need to brief on the project;
  • You stop him in the middle of the corridor and start briefing him on the project right here, right now; and
  • You give him a very high detail description like “It’s a mobile app”.

Result:

  • The brief takes 5-10 minutes;
  • No notes were taken;
  • No next actions were listed nor discussed;
  • The proper team members were not included; and
  • The person being briefed doesn’t necessarily have time for this today and now is stuck with a “surprise” new project he was not aware of.

2. The “Catch it” brief

Situation:

  • You go speak to the person and tell him a project is starting for a client and he should take care of it; and
  • You leave saying you don’t have more information for him…

Result:

  • The person is left completely clueless as to what to do; and
  • He knows he can’t ask questions since you have no more information.

3. The “high…very high level” brief

Situation:

  • You need to have an estimate done for a project;
  • You brief the person who will handle the estimate by informing him that you need an estimate for a “A micro-site”;
  • The person asks for more information; and
  • You answer… “Well it’s a micro-site!”

Result:

  • The person has no idea what to estimate and is frustrated by the lack of information.

4. The “New service” brief

  • You need to have an estimate done for a project;
  • You brief the person who will handle the estimate by informing him that you need to estimate a “Parade Float”; and
  • The person replies by saying “We do web here…” (which is true)

Result:

  • The person has no idea what to estimate; and
  • The person feels confusion around the new “service” we suddenly offer.

5. The “Client approval forward” brief

Situation:

  • You work hard to win a new client, not involving the team in any steps;
  • After much effort to win this new client, he decides to go forward with the project and sends his written approval in a mail;
  • You forward the approval mail to the team asking to start the project;
  • That’s it…

Result:

  • The team has no idea what is going on;
  • They are also discouraged by the “project brief” they just received.

6. The “When can it be done” brief

Situation:

  • You are in a meeting with a client who just agreed to have his websites done by your team;
  • Happy, you fetch the person responsible for production to meet the client;
  • Knowing he is completely clueless of the websites, you ask your colleague: “When can his websites be done?” while the client remains there, smiling, eager to know the answer.

Result:

  • Your colleague is put in a bad position where he is surprised, cannot answer, and must stay professional in front of the client; and
  • Gives a bad impression to client to see how his project started.

7. The “Client wants something else” brief

Situation:

  • Client gives you detailed information of what he needs;
  • You feel the client needs something else than what he his requesting; and
  • You brief the team according to what you think the client needs, and you do not share the original information the client provided to you.

Result:

  • The team is never able to satisfy the client, no matter how hard they try;
  • They are confused by the difference between what the client feedback says and what you say; and
  • Not only frustration build up, but so much time (and money) is wasted because of this.

In conclusion

Project briefs are the first impression of a project to your team, make sure it’s done right. Not only that, can you imagine if the clients knew how bad their project was transferred to the team? They would not feel confident the team could handle it, and they would be right.

Have you ever received a bad project brief? Share your story!

Freeze


Leave a comment

One great tip to help control scope

Freeze

Source: mparkes

As project managers, controlling scope can be very challenging.

You’ll want to avoid scope creep but if managed properly, scope changes can mean more budget. At first glance, this seems like a good thing, and in a way, it is. But there are a few others aspects to verify.

Be careful

For example, you can negotiate more time to the schedule, but this can result in the project dragging over a long period of time, and actually never end.

Another aspect to watch out more is as scope changes, team motivation diminishes. People need to close down projects and move on to the next challenge.

Still in the subject of team members, depending on how your organization work with resources, team members may not be available past the initial deadline planned. This may result in resource switches that add risk or cost to your project.

Projects should have goals too, and often goals are tied to a time-sensitive subject like an event, a new product, a contest, etc. By dragging these projects, the project goals may not be met.

So the tip? Negociate a scope freeze!

A great way to protect the project is to negotiate a scope freeze with stakeholders. This means that nothing gets changed until the current scope is completed. This doesn’t mean that planning for the next phase cannot start prior to the first one being done, it’s even suggested to start planning phase 2 while phase 1 is being completed, assuming you can secure the necessary resources of course.

Not every stakeholder may approve of this, they might feel secure with the idea that they can ask for any change any time, so it will be important to be diplomatic when discussing this and avoid forcing it upon them. Focus on the success of the project and the dangers of allowing constant changes.

Keep a backlog

If changes are requested or mentioned, it doesn’t mean they should be ignored. Anything that his discussed, even if a scope freeze was negotiated, should be noted in a backlog and reviewed when planning for a future phase.

It would be a great waste to forget all of those ideas.


Leave a comment

Continuous improvement – Part 4 – Tips

find-ideas

Source: ratch0013

In case you missed Part 1Part 2, or Part 3,  don’t forget to read the articles!

To end this 4 part article about Continuous improvement, here are several tips that will help you overcome the challenges that you may meet while trying to bring change in your team or agency:

1. Create a habit out of it

Just like everyone can get stuck in the routine of doing everything the same way all the time, you can create a habit of listing ideas, grabbing feedback, or adjusting/fine-tuning anything you can.

For example, every 3 months you can set yourself a reminder to ask people if they have feedback on a tool, or ideas to improve how everyone uses it. As time goes by, pay attention to the evolution of the feedback as it may change from “Everything is great” to “I found out about a new tool…”.

2. Gain buy-in from managers

If you do not have any power to use resources to make change happen, than sell your ideas to people who do have it. If they agree and make available the necessary resources for the change, then you will obviously have a better chance of making it happen.

To gain buy-in, there are several ways to convince someone:

  • Show the monetary gain of the change;
  • Show how things can go faster;
  • Show how better quality will be produced;
  • At the same time, you can use the current situation and show how slow, inefficient, or low quality things are at the moment;
  • Show people’s feedback;
  • Show are things are being done elsewhere and the result;
  • etc.

3. Accept mistakes

One of the reason we don’t want to tackle change is because we are scared of making mistakes. The thing is, you will learn a lot from your mistakes, and what’s important is to adjust right away when it happens.

If a new process just doesn’t work, either fine-tune it, or go back to what it was. Just don’t let it stop you, learn from it and let it bring you even further.

4. Find others

Usually, you will be able to find others who feel changes needed. Discuss with them, gather their feedback, their ideas, and get them on board to help you bring that change to life.

If you think you are alone thinking things need to change, you are wrong. Although at first it may look like nobody wants things to change, a lot do but are scared or just don’t think they can have an impact. People will join in, and make sure to include them as much as possible throughout the process of the change.

5. Think small / Think big

Changes can be very small and they can also be big. Do not neglect the small changes that can fine-tune your big changes into something even better. Just like sometimes the biggest, toughest changes are the ones that are going to bring the best results.

Vary the sizes of the changes you tackle. Even a small change sometimes keeps you motivated for the next change, just like finishing a small task during your day.

6. Think of others while planning

Unless the change is only going to affect yourself, think of others when planning how the change will impact everyone. The others will make your change live or disappear, if you neglect them, they will surely make your change revert to its original state.

How? Simple, talk to them, ask them what they like, don’t like, what’s their opinion on the path your change has taken, if they agree or disagree, ask them to test whatever your doing, involve them. Avoid doing this behind everyone’s back and then imposing the change suddenly without the proper training/support; your change will surely fail and everyone will just keep doing what they were doing before.

7. Ask these simple questions: “How can we be better?” or “How can this be better?”

The title says it all; just by asking yourself (or others) this question, you can be surprised of how many ideas can come out of it.

Do a brainstorm session and use those questions to start some discussions, and you’ll see there are many ideas that will pop out.

Also, ask these questions even if things are going well; just because a tool is great or a process is going well, doesn’t mean it can’t be even better.

In conclusion

This concludes the 4 part article on continuous improvement, I hope you enjoyed. Do share your ideas or stories of when you brought change within your team.

Surprised


Leave a comment

What’s scope creep and tips to avoid it | Part 2

Surprised

Source: grietgriet

Scope creep is a very important subject, something every project manager is challenged with.

In my previous article What’s scope creep and tips to avoid it, I listed a few tips to help people face those challenges, and that article was very popular, so I thought it would be great to add more to it and focus on the team:

Scope creep can be 100% an internal issue, so watch out!

Often we are under the impression that scope screep is something we forgot, or something the client asks for and we have no choice but to accept for whatever reason. But, you know what? Sometimes, it’s simply an internal thing.

Often, what will happen is that scope is defined in a certain why, and then, from there, you will create the estimate, and work will get started. Everything goes well, and as you discuss with team members, they sometimes casually mention some stuff like “Yeah once that is done, we’ll need ‘this’ done and then we’re good” or “we need this because we have ‘this’ and ‘this’ to do”… All the while in your mind you are telling yourself: Where does this all come from?

The reality is, no every team member will be “connected” to the budget as you are as a project manager. This is completely normal because they are focused on their own role and you should be focused on yours. The impact of this is some small tasks (or bigger) will be neglected in the documentation or even in the estimate but here and there you will find out that it MUST be done.

Why? Well, it varies; it could be a client expectation not shared with you, it could be a technical requirement mentioned absolutely nowhere…Or something else!

Regardless, this is tricky, but there are things you can do to help prevent this!

Focus on the long term

So, when it happens and you are “stuck” with the request, you may think this is the end of the world, your project is going bad because of it, and nothing can be done; whether this is true or not for your current project, you can focus on the long-term, which are your future projects. How? Well, by discussing a specific issue and adjusting for the future.

For example, if client expectations around different deliverables were not clear and were “implied” somewhere, talk to the person responsible of managing the client and explain the impact of those expectations being “hidden” from you. The thing is, that team member may have the best intentions in the world towards the client, but he may not realize the impact of the added work. So, the best way to make him understand is to explain gently to him the impact by showing underage caused by the added work he didn’t share in the beginning.

Manage team expectations

We’re always talking about managing the client’s expectations, but what about the team’s expectations? There is absolutely nothing wrong with telling team members that anything other than what’s inside the estimate will NOT be done so “be careful”.

However, it’s very important to consider that whatever you say “will not be done” may be an absolute “must” to your project. This means you have to use a specific vocabulary with your team.

Try using:

  • Are you sure we included everything we need for the project?
  • This here is what we’ll be doing, we won’t be able to afford anything else, are you sure it’s accurate?
  • Are any other client expectations forgotten here?

Avoid:

  • We won’t allow anything else than what’s included here
    • what may happen is that some “things” will come up that will literally prevent your project from being functional if it’s not done and you won’t be able to tell your client you “forgot” this
  • Saying nothing
    • people may think whatever they are holding back is “implied” in the documents

Manage team expectations… again!

Repeating myself? Well there is more to it than what’s above!

Scope creep can surprisingly be with team members spending more time on certain tasks because they thought they could so they made the design or the feature “more awesome”. It could be considered gold plating in a way.

You have a tight budget? Poor or no contingency? Well, tell your team! As much as they are not “budget focused” as you are, if they are remotely committed to the project’s well-being, if they understand the budget being tight or being in a horrible shape, there is nothing wrong with letting them know and reaching for their cooperation.

This will have a huge effect on how they make decisions or how they plan their work.

For example, a designer may take less time to search for a “miracle” image for his design and settle for one that’s just plain great. A developer may take half the time to code a certain feature because he’ll plan his code a different way.

Regardless, your team must know the situation and they will take it into consideration before taking more time than planned to do the work.

In conclusion

As you can see, the way you communicate with the team can have a tremendous impact on how scope creep affects your projects. Take the extra time to your team members, even if it’s too late for this project, it may be very positive for future projects.