The Importance of Quick Wins
It’s important for a project to get off to a good start, especially when it can easily get bogged down on the first line item of a plan and languish. The following article discusses some ways you can ensure your project gets off to a good start and ultimately ends with a great finish.
A story.
The company had been thrashed in the space of ten years. Where previously it had employed hundreds of resources, after four layoffs and one bankruptcy it was now clinging to life with less than forty. Investors had had enough and ordered the sale of the company.
The new group of investors saw opportunity, and immediately started making adjustments. Some were large (like getting ridding of even more people) and some were small (like providing free drinks in the cafeteria). Additionally, they adopted a philosophy of transparency that had not been seen heretofore. The old regime talked the talk of transparency and inclusiveness but it was just that…talk. The new owners walked the walk, and the difference was night and day.
One of the first things they did was to share the financials with the entire company as soon as the numbers were ready, which was in just under a month. The income statement was projected on the wall in the conference room, and showed that while the first half of the year had incurred a net loss, more profit was realized in the current month than in the previous six months.
This made the team feel great for two reasons. First, it was the first time anyone had ever shared the financials outside of a small group of elite executives. Second, the company was actually making money in the short term. The quick win was a harbinger of things to come!
What is a Quick Win and Why Is It Important to Your Project?
A quick win is known by many names: slam dunk, no brainer, low-hanging fruit, sure thing, and easy peezy lemon squeezy, to name just a few. In other words, quick wins are those things that you go after that are almost guaranteed to succeed.
Mark E. van Buren and Todd Safferstone, writing in Harvard Business Review, discuss some potential drawbacks to the concept of quick wins for leaders coming on to teams. While important to secure confidence in leadership, sometimes quick wins come at the cost of the team.
When a quick win is about celebratingthe team, rather than just an individual’s quest for change, they can be valuable.
Consider using quick wins on your project and your team for the following reasons:
Get Everyone Motivated – Seeing results almost immediately after an effort is expended is very motivating for a team. In the opening example, once everyone saw the numbers they walked away with fire in their belly and zip in their step to keep the trend going. They knew that the positive results were directly related to the activity they were engaged in, and it made them want to do more. They were now eager to implement greater cost saving measures, and brainstorm more revenue-generating ideas, improved processes and other great ideas that would all contribute to the bottom line.
Fuel Momentum – Every project needs momentum to keep it moving forward, and there’s nothing that fuels it more than reaching a milestone, checking it off your list, and putting a particular phase of the project behind you. Quick wins propel everyone in a forward direction and provide stepping stones for further progress. Sometimes it’s hard to see the progress of a project while you are moving forward, but when you take a quick look in the rear-view mirror it becomes very apparent how far you’ve come and how fast.
Establish a Cadence for Your Project – The cadence of a project is the rhythm at which your project moves. Think of it as the pace someone walks with, such as slow, deliberate, lumbering steps or quick, short, and choppy steps. There’s nothing wrong with either pace, it’s just a matter of how long someone’s legs are and their disposition. Each of your projects has a unique disposition and personality as well (and some have legs). A short churn-n-burn project that needs to be wrapped up in a matter of weeks needs quick wins faster than a project that will continue for a couple of years.
Feel-Goodness – Last, but certainly not least, is that quick wins feel good to you and your team. There’s nothing like checking a deliverable off your list and then being able to report on it at the next project status update meeting. The positive energy created from accomplishment feeds into the energy you and your team need to move forward into the next phase of a project.
Quick wins create a motivated, forward-moving team that gives everyone associated with that project a warm and fuzzy feeling.
Set Yourself Up for Quick Win Success
Is it possible to guarantee a quick win? Yes, if you already have the win on the books and then advertise it later. Now, some people may object to such a tactic, but hear me out.
Think about the income statement example again, and new management’s deliberate move to quickly get information out. They knew going in that they were going to have absolutely no problem achieving a new record. They had eliminated massive amounts of debt that had been drowning the company, and were able to renegotiate unreasonably high contracts to something much more fiscally responsible. This win was already in the bag and now it was just a matter of letting everyone know the results.
Can this be applied to your projects? Absolutely. Just get a head start. You can be a little creative when it comes to applying resources, asking for people to work a little bit more here and there (perhaps in exchange for additional time off later) or prioritizing deliverables. The end result is that you’ll be able to ensure that quick wins are lined up and insure they are impactful.
What type of impact will quick wins have? People on the team will begin talking to others about their recent success. It’s good (and unusual) to have this type of news to spread and it will be a welcome change to the incessant flood of things that go wrong. Good news trickles into other areas in the organization, improving you and your team’s reputation. It’s also up to you to help spread the word of these quick wins.
Nature hates a vacuum, and most companies take the path of least resistance and fill an information vacuum with how poorly things are going or how broken things are. You now have the success stories you need to keep that type of information out of the conversation and change the topic to something positive.
Do yourself and your team a favor and identify and focus on those quick wins. You’ll set the pace for the rest of your project and allow everyone to have a feeling of accomplishment along the way!
Credit: projectmanager.com
Tips for Quality Testing
Ah, the lowly testing phase. In all-too-common scenarios, the testing phase is cut short due to scope creep, which extends the deliverables too close to the project deadline. Or sometimes, testing is simply cut out to push an earlier release date. Sadly, many teams omit the critical testing phase simply because they fail to plan for it.
The testing phase encompasses the project tasks required to check that the products you have built do what you said they would. Shoddy testing results in shoddy products, so it needs to be detailed and thorough if you want to get a quality result. Testing is not something you want to cut.
Here are nine tips for making sure your testing phase properly planned for, preserved and defended like Fort Knox!
1. Cover All Your Requirements
It sounds obvious, but make sure that your test plans include all the products and deliverables from your project. If you aren’t going to put some part of the project through quality testing then make sure this is clearly specified and you document the reasons (and that everyone agrees).
Deciding to omit various parts of the project from testing should not be taken lightly. Define which parts of the project can be accomplished at automated testing tools and what test suite you’ll be using. Missing requirements out of quality testing means you won’t end up with a robust product at the end. Overall quality will suffer and there might be some aspects of your system that don’t work at all.
2. Prepare Your Documents Early
Don’t leave it until the testing phase of your project to prepare the test scripts or use cases. Pull them together as soon as you can, ideally as you are documenting the requirements or while the system is being designed.
You can upload the test plans and other files to your online document storage files. Project team members can access them while they are developing the product to help them think through how it is going to be used and therefore how it should be developed. Also, it saves you time and lets you hit the ground running when testing is due to start.
3. Involve Your Testers Early
Use your project resource plans to identify who will be doing the testing on the project. Then get them involved in the project as early as you can.
The testers can help you write the test scripts and other documentation such as a test plan. More importantly, they can also help shape how the development is done and they represent the users on the project team if you don’t have a user rep permanently seconded to the project. The more they know about the project and what problems the system should be resolving for users, the better they will understand the testing requirements.
4. Prepare for Bugs
Go into testing aiming for a quality result. That means testing the system to destruction! Prepare your users for the likelihood that they will find errors and that this is a good thing. (Remember how long Google was in “beta” with Gmail?)
Finding errors can be disheartening. However, it’s not realistic to think that there won’t be any. That’s why you test – so they can be uncovered and resolved before the system goes live. Managing the attitude of the team going into testing means morale won’t dip when they start logging pages of errors.
5. Break it Down
Break down your products to the smallest unit you can. That gives you very granular testing. It’s a thorough and robust way to quality check every single part of your project.
It’s not always possible to notice errors if you are testing at too high a level. By breaking it down you’ll cover everything in a logical and structured way, ensuring the best quality.
6. Analyze the Test Results
The results of a quality test are ‘pass’ or ‘fail’. When a requirement fails, be prepared to work through the reasons for that with the rest of the team or the developer in question. A deep analysis will help you get to the root cause of the failure. That will enable the team to fix the issues more quickly and in turn save you time with retesting.
Many heads are better than one. The user’s perspective on how to resolve the problem and get a quality result could be quite different from that of the development team. Draw on all your experiences and collaborate to pin down exactly why something failed testing.
7. Group Your Quality Tests
Look critically at your test scripts or use cases and see how you could group them together. For example, everything related to the user experience could be one group. Anything to do with taking payment goes in another. Requirements related to logging in and processing transactions could be a third.
You’ve broken down your test requirements into really small blocks to test at a granular level. Now you’re grouping them together to make it easier to manage both on your project plan and when it comes to allocating tasks to your team.
Grouping your tests together also makes it easy to find out what needs to be retested if you apply bug fixes. Normally you would test everything that relies on new functionality again, just to ensure it hasn’t broken through the application of a fix or additional feature. This is called regression testing. Using groups lets you quickly identify the tests that need to be performed again.
8. Test Performance
Up until this point you’ve been testing functionality: what the system does. Don’t forget to also test how it behaves. Performance testing uncovers issues with how systems work such as:
Slow response times; how long it takes to refresh the screen or complete a transaction
Security problems and vulnerabilities
How the system responds to multiple users accessing records at the same time
Whether you can audit the system.
And so on.
It’s much better to uncover performance problems at this point in the project. You could argue that it isn’t a quality outcome if certain performance measures are not met. Testing performance will minimize the number of complaints you get from users when the system goes live.
9. Share the Results
Whether your quality tests result in a pass or fail result, you need to share the results with the people who matter. Use online project management workspaces to manage the flow of information between the test team and the developers. Online discussions and instant messaging make it easy for the relevant teams to talk to each other and share the outcomes of the testing.
Better communication encourages trust within the team – and you want the developers to trust the test results and the testers to trust that what comes back is really fixed. A streamlined approach to data sharing also speeds up getting results and bug fixes. Plus, a team that has planned for and committed to the testing phase will be its biggest advocates if it is threatened.
Credit: projectmanager.com
Guide to Motivating Technical Teams
Whether you’re setting up the next hackathon or leading a diverse cross-functional team, it’s important to know how to keep your team motivated.
Technical teams may be made up of everyone from the just-out-of-college app whizz to the CIO. The nature of many projects means we have to engage with technical experts at every level—you might be a techie too.
Managers who regularly lead technical teams (as opposed to creative teams or sales teams) learn strategies that support their operational success. Whole cultures can be embedded in organizations around teams; so much so that new leaders needing to step in and run projects and operations find themselves struggling to connect (and motivate) the team and meet them where they are.
Technical specialists are often key project resources on the team, especially since technical work now touches more and more industries. Learning strategies to address different skill sets can be an important tool for any manager.
Why Tech Teams are Unique
‘Technical’ covers a wide range of skills from software developers to system testers, network architects to telephony specialists, database analysts to security experts – and more. It’s impossible to define a typical technical team, due to the wide range of skills and experience levels on any team, but there are some features that are common enough across technical teams to warrant a mention.
Richard Turley and James Bieman, at Colorado State, defined 5 core competencies for software engineers: they are team oriented, seek help, help others, use prototypes and write/automate with code. Those are great skills that any technical team member should aspire to and might already have. Additionally, tech teams in general, it could be said:
Love a good problem: By the nature of what they do, technical experts are often problem solvers. We see that through the culture of the hackathon and other technical challenges. In and of itself, solving problems can be motivating. Framing your project challenges in such a way that they can be used to bring out the best in people is a good team-building activity.
Test to kill: Technical teams often break things in their development and staging environments because it helps mimic what could happen in a live product environment. For example, businesses employ ethical hackers to try to break their security protocols and get access to sensitive data. The attempt to break a feature (especially if they succeed) can cause friction between the dev team and a manager when the latter isn’t familiar with testing practices. Be sure to spec out all the requirements for testing well in advance so your technical experts can plan accordingly.
Are task-happy: Some technical teams can be heavily task-orientated. This can be a huge advantage in project work as they are used to task lists and methodically working their way through activities to reach a clear and defined conclusion. However, we’ve seen it also cause problems when the project changes direction quickly. Communicate often to make sure all issues are captured and that new tasks are added as needed.
Are secretly creative: There is more than one way to configure a server or write a line of code! Technical teams are often highly creative and critical when it comes to generating solutions. However, we’ve also seen a desire to innovate have a negative impact on projects because a change hasn’t been documented thoroughly or extra features are added at the supplier’s cost when they weren’t requested in the first place (you’ll hear this calledgold plating). Encourage creative problem solving, but set boundaries so that everyone knows how far they can go. Give technical experts the chance to put forward solutions and officially add them to the project plan with the correct approvals and changes to documentation if required.
There are certainly more nuances than what are listed above, but these are common skills and scenarios found on technical teams.
What type of environment is motivating?
Everyone is motivated by different things. What spurs someone into action in one situation won’t work at all for someone else, or even the same person in a different environment, which means that you can’t rely on one motivational technique to boost the productivity of your team (technical or not).
Instead you have to create an environment which is motivating in different ways to different people.
There are many great names behind complex motivational theories like Maslow (the hierarchy of needs), Herzberg(hygiene factors) and McGregor (the theory of X and Y). However, there are some common themes that you can take away from all the theories and apply to your project environment.
You won’t get better results with more pay. Money does not motivate people, whereas lack of money can demotivate them, so make sure your team members are paid adequately and within the market rates for their skills.
Involving people in decisions which affect them helps to motivate them. People generally like being able to choose how to get things done. Telling people what to do gets you compliance (sometimes), but not motivation.
Align your work to the values of the team – or hire people with values similar to the organization’s values to begin with. People find it hard to get motivated when they don’t believe in what they are doing.
These tips will help you create an environment that has the right conditions to motivate your technical teams. Now let’s look specifically at:
10 Carrots for Tech Teams
Okay, motivation is more than carrots and sticks, but too often managers default to a simplistic, one-size-fits-all approach. It’s worked for them for years, so what’s the problem? Well one, people are not robots. Yes, even the technical team members, who, many of them, might be have the occasional robot figurine on their desk.
Two, the world of work is changing. Not only are new generations of team members bringing new technologies and ideas to teams, but the nature of how we work has changed too. Top-down management is less effective than it used to be, replaced increasingly with collaborative ways of working.
What this means in practice is that you must diversify your motivational strategies to meet these new challenges. Here are ten ways to shake off old patterns and find new ways to motivate:
Reward Results
Technical project work has peaks and valleys (like a lot of jobs). Reward your team’s results, not how many hours they spend at their desk. Frequently, tech teams are the last ones at the office, due to the demands of technical work such as being on call during the project’s go-live times. Some are coding at home on the weekends or making runs back to the office to check that the installation on Friday is still in good shape.
As a manager, your job is to get results, not to clock watch your team. Measure their contribution and that elevates your workplace to one where they are trusted colleagues.
Delegate
Delegate work to your tech team so they have the opportunity to take on non-technical, managerial tasks as well. This broadens their skills and shakes up their routines. Remember that this won’t work for everyone – some of your technicians will be happy to stay in technical roles and aren’t interested in moving into management positions. Even so, you can empower your team learn to delegate in turn, so they have more time to focus on what’s really important.
Demand Solutions
You’ll probably have heard the saying, “Don’t bring me problems, bring me solutions.” Put this into practice with your team. It will motivate your team to think through issues and invite hem to come up with their own ideas for solving problems. Remember to praise the effort that has gone into the thought process even if you don’t act on their solution.
Treat them as Experts
Your technical team are experts in their field so treat them as such. Talk about them as experts to boost their reputation internally. Encourage them to contribute to industry debates, publications, conferences and so on, and to share their knowledge internally too. Ask the more senior team members to mentor junior colleagues and encourage everyone to share lessons learned.
Communicate
Communication is important at all levels on projects, and it’s a motivating factor when it involves the explanation behind decisions. Knowing why something is happening helps people tackle the work with a sense of inclusion and understanding that is far more motivating than simply being told what to do.
Researchers from the University of Sheffield in the UK found that not discussing problems adequately within the software engineering team caused more issues than disruptive events such as not drawing up the budget correctly. The lack of discussion created problems like false confidence in the solution and the refusal to make sensible contingency plans – all of which you’d want to avoid on your project.
Avoid the Naysayers
Step away from the troublemakers! You know the ones: the people who constantly have negative things to say. Keep the complainers away from your team or they’ll bring you all down.
Take Advantage of Errors
Unless the error is as a result of downright sloppiness, stop dishing out warnings for mistakes. Start looking at them as opportunities for improvement. Hold retrospectives and ask the team member who made the error to present the situation to the team in a non-judgemental environment. Let them talk through what happened and then discuss as a team what you can do to prevent that from happening again.
Put those suggestions into practice so that the same technical errors don’t crop up on other projects in the future. Adopting the principle of pair programming, where two developers work together on the same task, could help avoid problems in the future.
Use Their Skills
Individuals perform best when they feel the work is challenging, and that’s certainly the case for technicians. While it’s wrong to stereotype all technical people, you’ll definitely find people on your team are motivated by applying their technical skills to solve problems. Conversely, being underutilized is a demotivating factor.
Cycle tasks so the burden doesn’t always fall on the same person. Find ways for your technical resources to stretch their skills on a range of projects and problems.
Foster Innovation
Because it’s in their nature to explore innovative working practices, your team might not think their fantastic solution it’s a big deal. Look out for those moments of innovation and reward anything that is adopted as the new project best practice. If you get better results as a direct consequence of something that a team member has changed, celebrate it! They might think you’re weird for making a big deal out of something they take for granted but secretly they’ll be pleased that you noticed the improvements they have made.
Remember to apply some rigour in recording what has happened and why. You won’t always need a ticket but when you do get one raised retrospectively to maintain that audit trail.
Help Them Handle Stress
Stress can be the unwanted consequence of working in a technical environment. Some dev teams foster a culture of stay late or die trying. But for other teams, the nature of the work is such that system maintenance must be done outside or normal business hours and your team may be on call to deal with system crashes as well as trying to get your project work done.
In a nutshell: watch for burnout.
Researchers from Carleton University in Canada investigating the social nature of agile software development teamsfound some team members were highly stressed after a whole day of being ‘on’ and engaging in collaborative interaction, especially when they were working with the same peole every day. If you notice one of the technical team struggling, step in to find out why and work with him or her to adjust their workload or to develop techniques to help them manage the stresses of the job.
A project environment that is too laid back, on the other hand, helps no one as there’s no pressure to get anything done. You run the risk of your project resources getting lazy and missing the few deadlines that you have. Find a balance between a highly stressful environment and one that is so stress-free that the only thing that happens is procrastination. Planning work effectively, delegating tasks to the right people, sharing status updates in real time and ensuring everyone has a clear view of the project’s vision are straightforward things you can do today to manage the stress levels on the team.
Creating an environment where everyone has the same view of the project and can manage their work effectively from the same workspace makes it easy to track progress and support your technical teams.
Credit: projectmanager.com