As a Project Manager, I cringe at the thought of scope creep! However, as a former WebDevStudios client, I know I am guilty of it. I’ve learned I am not the exception to the rule on both accounts. So, here are a few things I’ve learned about scope creep and how you can manage it.

What is scope creep?

After a website project has started, and the scope of the project grows beyond the original plan, that is considered scope creep. This can happen for a number of different reasons. If a project’s requirements are not well defined and outlined at the start, new requirements are likely going to come up throughout the life cycle of the project. Similarly, a lack of transparency and poor communication during the project can result in additional work impacting the original scope.

A surprising reason for scope creep…

I have found that there is another reason why scope creep happens: excitement. Nothing can prepare our clients for the way their new website looks and how it functions. There is a big difference between the mock-up they approve during the design phase of the project, and the functioning site they see on our status calls. At the beginning of a project, it can be difficult for a client to imagine how things will turn out. Once they start seeing demos, they start to see the potential. With this potential, comes new requests and expectations—thus, scope creep.

Scope creep management

And there’s the rub. As a Project Manager, you don’t want to crush your clients’ dreams, but you have to manage timelines, budgets and expectations. Our goal, then, is to minimize the risk of scope creep throughout the website project. This starts even before the discovery phase. By sharing with our clients sites in our portfolio, they are able to envision what their site could also do. This empowers them to ask for certain functionality before the scope has been established. During our extensive discovery process, we are able to flesh out what the requirements are.

Accepting the reality of scope creep

Finally, it is as important to have a plan to deal with scope creep when it happens (since it is inevitable, like the common cold) as it is to have plans in place to minimize the risk in the first place. We cannot accommodate every new request or change that comes up during every website project for every client. What we can do is explain their options through change requests and appreciate where the client is coming from—a place of excitement.

What methods or strategies do you use to manage scope creep? Tell us your tips in the comments below.

The post Why Scope Creep Happens appeared first on WebDevStudios.

We Perform a Client Discovery

Once you’ve gone through the discovery and design phase of the project life cycle, your Project Manager will begin preparing for the development phase. At this point, your Client Strategist has created your project plan and your budget is set. We then will take that project plan and will create individual tasks for the development team. We then work with the Lead Engineers to determine how many hours each task will take.

This step is critical for budget planning. We try to always assign tasks based on the developer’s skill set. If we know a developer is strong and fast in a particular area, then we want to make sure that developer gets that particular task. They will likely need less time so that saves precious hours that can be allocated elsewhere.

We also set aside hours for QA, calls, project management, and launch. These are items you may not realize add to the bottom line. We account for as much as possible so that there are no surprises later.

We Communicate to the Client Their Responsibilities

The best way you can help ensure the project stays on budget is to be as detailed as possible during this initial discovery phase. Let us know how the site should behave:

• What do you and your users expect?
• What are some pain points with your previous site?
• What functionality do you need?

User stories are not required but greatly help us during this phase. Vagueness and ambiguity in the project plan lead to budget risks down the line. One sentence can be interpreted in many different ways by the project manager, the engineer, or you. If you see any vague or ambiguous statements in the project plan, work with your Client Strategist to clarify before the project starts.

Being thorough and detailed initially will prevent us from having to use more time to redo a certain feature down the line if it doesn’t meet your expectations.

We Inform the Engineers of Your Budget

After we’ve broken the project into individual tasks and estimated hours, we schedule a kickoff call with the engineers. We go through the project plan budget to ensure the engineers are aware of what they are building and how much time they have to build it. It is at this time they can raise awareness if they think a particular task is going to take longer than anticipated. Knowing this ahead of time allows for us to shift more hours to that particular task.

We Take Special Measures to Ensure the Project Is on Budget

The Project Management team monitors the hours being spent on tasks daily. When an engineer gets close to reaching their allocated time for a task, we will determine if the task is on budget. If that task is at risk of going over budget, we then see what ways we can make that time up. There may be a task that came under hours that balances the one that went over hours. Minor overages are expected, but if the overage is becoming severe and that particular feature turns out to be more complicated than expected, we will work with you to see if there are other areas of the site we can simplify.

WebDevStudios also adheres to coding practices that ensure we spend less time debugging during the QA phase.

We’re Open to New Requests

When I went shopping to prepare for my trip, I only thought I would be purchasing clothes. As I was leaving the mall, the guy at the kiosk asked if I wanted to also get my teeth whitened. This was not something I had planned for or expected but now knew I needed because… #birthdayselfies.

During the development process, you may discover new functionality that your website needs but we may not have accounted for it in the budget. This is expected. To make sure we stay on budget, let us know what that new functionality is and we will add it to a backlog. After development is complete, we will go through the backlog and complete new items if the budget allows. If we’ve exhausted the budget, we will work with you to increase the budget to account for those new things.

Final Thoughts

As I prepare to head back home to Las Vegas, I’ve come to some realizations about budgeting. I had an amazing and spontaneous trip! It did not go exactly as I had planned it, but I stayed committed to the budget I had set. Instead of wasting money on a hotel, I opted to stay with family and allocated more of my budget on front-of-the-line passes at Universal Studios and trying new restaurants.

The initial budget planning is key but so is managing that budget throughout the project life cycle. It requires commitment, diligence, flexibility, clear communication and the ability to handle unexpected situations. By using these steps above, we can reach our ultimate goal of delivering great websites on budget—just like I was able to enjoy a memorable birthday weekend while remaining within my own budget.

When you’re ready to have a website project delivered on time and completed on budget, contact us. We’d love to partner up!

The post Guide to Completing Website Projects on Budget appeared first on WebDevStudios.

How could this have happened? You planned so well! And let’s be real: you’ve probably made the most perfect project plan you’ve ever constructed…at least since the last one. How could someone have such a disregard for this picture of perfection you’ve worked so hard to achieve?

I’m just going to come out and say it: This will happen (to some degree) with any project your team will embark on. The true test is how you roll with the punches. Here’s a few tried and true ways you can keep your team on track and pivot with the best of them!

Is it in scope?

The first thing you should do with any project your team is taking on is read the scope of work (SOW). What are you contracted to complete for the client? I highly recommend reviewing the scope of work at the start of any project with your account executive to ensure you and your team have a clear understanding what’s required. I also do this as part of any project kickoff call with the client to ensure all team members are on the same page. This review also serves to set expectations from the project onset. If you suspect there is a new feature request, confirm if its out of scope first.

Be upfront with your client

When you identify a new request coming through from a client, it’s critical that you let them know that it’s just that–a new request beyond the current scope of the project. It can be intimidating to utter the words “out of scope,” but remember, this is an ongoing conversation with your client that should be open and honest. Agreeing to “take a look at” a new request or that your team will “try and get it done” for the sake of avoiding potential confrontation will only end poorly. You will either end up with a project over budget with extended deadlines or will have to readdress the issue with the client to tell them that it is, in fact, out of scope. I can promise you, mentioning a feature is out of scope two weeks after you agree to “take a look at it” will not leave you with a happy client.

Gather all the details

The most important thing you can do for your team and client is to get a full grasp of what the client’s objective is with their new request. What are they hoping to achieve? A better user experience? An easier work flow? A more functional feature? For any goal there are multiple solutions. Collect all the details you can from the client on the goal, their expected workflow, and anything they’d like to avoid. You can then bring this information back to your team internally to discuss how you can better approach the new request.

Meet internally with your team

Time to face the firing squad. Its never easy to tell your team to throw the brakes on their otherwise unimpeded work flow. I can promise you, it will be infinitely easier if you’ve done your homework and come bearing the information your team will need to formulate an action plan. Schedule a meeting and start brainstorming solutions. Key questions to ask yourself and team for each proposed solution – How can we easily achieve the clients goal? How long would you estimate for completion? Who is able to be scheduled to complete the new feature? What are the trade offs for the solution, if any?

Make a recommendation

Once you’ve met with your team you should have a few options to meet said goal. Now’s the time to focus in on your team’s recommended approach to the new request. Presenting a client with all options can open the door to many more updates and revisions within the project that might further impact scope. Express to the client what your team thinks would be the best solution, whether its in or out of scope, and why it’s the best solution.

Most importantly, SELL. IT.

If you truly believe in your team’s solution, fight for it and do your best to explain to the client why it’s the best solution for them as well. You can’t always guarantee they will agree but you can give your team a fighting chance. If they are hesitant, explain the potential pitfalls of other solutions (i.e.will require more time to complete, will be more costly, creates a poor user experience – the list goes on and on). Just remember, the goal is to provide your client with an amazing website that aligns within scope and their needs!

Update your project plan

Once you and your client have landed on a solution, it’s time to get the team scheduled to develop the new feature. If your team’s already frustrated by having to switch gears, don’t double down on the hurt! Make sure you adjust your development timeline to accurately reflect the amount of time they need to complete the work. Accurately estimate your time, convey this to the client, and make them well aware that any update will take time. Always update your project plan and development timeline to reflect it, too.

I hope these tips will help you on your way to smoothing out those new feature request hurdles and taking client curveballs head on without fear.

The post How Project Managers Handle Client Curveballs appeared first on WebDevStudios.