Customer Expectations

  • Gathering Information - Time and Materials

    Time and Materials

    This is a continuation from our Fixed Bid post.

    It could be argued that time and materials is the best approach for both sides. If the agency or developers know what they are doing, it should be easy to come up with a budget and time line that could be met within that budget. You can break down the hours into buckets that allow for shifting of the time to keep within budget. Agile will allow the agency to demonstrate progress and ensure that the client is kept in touch with their project. Why doesn’t everyone just start with Time and Materials? I think in reality most developer/agencies are doing this under the guise of fixed bid. The following takes place: Client engages with agency. Agency agrees on the scope of the project. Client expects the scope and cost to remain the same. The scope changes, the agency doesn’t say anything. Finally, the agency says that they need more money for “X” feature and are now months into the project.

    The best approach is to define stories within the Epic(s) and assign some effort to what it will take to complete the story. If the story is well written the details of the feature are inherent because of the outcome of the story. Let’s go over an example.

    Story: I would like to get 2 burritos and 2 chilitos from Taco Bell. Looking at this as a developer I want to discover some things. I need to know where the Taco Bell is. I need to know how I am going to get to Taco Bell. I need to know if I will have enough money to pay for the Taco Bell and finally I need to if it will be open when I go there. There are of course a 100 different things that could be involved but these cover the main points and the reason we use a story is so many of the obvious things don’t have to be detailed.

    Our discovery finds the following: I will use my Scooter to get there. I have $10 which will be more than enough money to pay for it. Taco Bell is open until 2am so I will leave early enough to get there. The scenario can run deeper but you get the point. We don’t have to define what is in a chilito and what is a scooter. These things are assumed in the project.

    The key to a successful project using the time and materials model is good reporting and a clear budget. The advantage is we have a fluid environment to work in where things can get done. The con’s are that it will be easy for anyone to derail the process.

    The information gathering is partially done upfront and partially done during the project. (The more upfront the better!)

    For next time I will write about "Sharing with a team"

  • Gathering Information - The Fixed Bid


    This is part of my on-going Customer Expectations Series

    The biggest problem facing developers when working on new projects is how they gather their information. It is more than likely that an agency or developer gives an estimate before knowing the entire project. But how can you know the entire project? Sometimes the client doesn’t know everything that is part of a project.

    The simple answer is to do discovery on what you are doing and from this discovery you write a SOW. I will lay out two different formats for projects and briefly describe the benefits of each. I will split this post into two, one for Fixed Bid and one for Time and Materials.

    Dead Termites.

    I covered the topic Fixed Bid in my article “Things Change - The Fix Bid Project”. The hardest part is knowing what you are bidding on. When you hire a builder to fix your floor boards and after they have removed them for repair they discover that you have termites and suddenly the cost of your project has quadrupled. The difference between the home owner example and the software project example is the homeowner can see the dead termites. If only we had dead termites in software development we could show the client what we found and demonstrate why we need to add time (and money) to the project. [We do have bugs] The point is that things never stay the same and whether the client comes up with something new or the developer finds something, things change. The danger in the fixed bid as that no one takes into account that something could change. You would think that the client is the one who drives this rigidity, but the responsibility it on the agency and how the agency communicates what they will do. If the client believes that the agency or developer will do everything from the start and that everything is not well defined. If the “EVERYTHING” is stated verbally as; “Yes of course, that is easy”, then the client would believe that everything is included. Even worse, the effort needed to complete is assumed to be easy which leads to mistrust because everything is taking longer.

    The key to the fixed bid is a lot of discovery and documentation. The documentation has to be so in depth that it will be hard for the client to argue that some unknown feature that is later discovered should be included. To mitigate much of the risk the agency should build in risk. If anything is missed in discovery, the built-in risk allows for a cushion to pull from without having to ask the client for more time and without the agency frustration of doing work for free. What can’t be invented is time.

    Next week I will publish thoughts around Discovery on a Time and Materials Project

  • Outbound


    In continuation of my Customer Expectation Series I want to focus for a very short time on Outbound communications. (I promise this is a short article)

    I am a strong believer in the idea that what works in one arena works in another. For example, the same practices that are successful with a customer will be successful with employees. To be more specific if we communicate as much internally as we do with a client (or vice-versa) it will only increase the probable success of a project.

    This leads me to our new car. We recently purchased a used car from a broker. Now when you first decide to buy a car everything is exciting and everyone is happy (Honeymoon phase). But as we progress through the process and more specifically, after you give them a check, then the communication is a little more scarce. Promises are made and perhaps not followed up on. Sound familiar?

    The same things hold true with any project. The more that we (the agency or developer) communicate with the client, the more everyone will be in tune with what is happening. This is Project Management 101. Communication is King and it is up to us as project leaders to communicate with the client often. When was the last time a client said to you, please don't call me so often?

    This is not to say that you should call your client every hour, but you should decide on key check-ins. For example, during your ramp up phase when it is critical to collect data, it is good to check in every day. During the build phase, you can move to once a week and finally prior to launch go back to every day.

    The idea is simple. You as the project manager need to initiate the call and you need to do this more than you think is necessary. (Unless you have already read my articles or the client files a restraining order)

  • What we expect in a Project Manager



    This article is a continuation of my series of articles around customer expectations. After reading the article from Pam Ravenscroft from Space 48, "Project Managers, where the hell are you all?", I got thinking about how important that the PM/PO's understand what they should be doing. More importantly, what are their priorities if they could only accomplish a certain amount of things in a week. The list I came up with is by no means a complete list. It is the list I came up in my head on during my 2-minute shower on November 15, 2016, my 5-minute drive to work and finally after reading Pam's article. (Yes I know, too much detail.)

    Scenario: PM/PO has to do make sure certain things get done during a one week period.

    So if we had to deliver something in a week, what would that be? The deep dive on this exercise is to get the PM/PO to ask certain questions that have to get answered. By asking the questions they can then enable themselves to deliver objective information to the client.

    He is my incomplete list, it is broken into two parts. Client communication and team communication. You will see that team questions will answer the client questions.

    1. How long do we still have to spend on the feature?
    2. What is our capacity this week and are we on track to deliver on time?
    3. Have changes impacted the timeline?
    4. Are we working on features we can work on while still getting requirements for additional features?
    1. What is the due date of the feature?
    2. How long have we spent on the feature?
    3. How long do we still have to spend on the feature?
    4. What are the changes on this feature and do they impact the timeline?
    5. Have you communicated this to the client? (REPORTS!)
    6. Have you spoken to the client this week about how they feel about the project?

    Hopefully, from the simple list of questions, we can learn all the things we need to know to communicate to the client. The communication needs to happen on a weekly basis and the more you can help the client understand when something has changed the better. So a great example is when you find that some feature will take longer than first estimated. This should be communicated the minute you as the project manager found out.

    So now, we had the subjective portion to project management. For this, I want to turn to Pam and her recent article. To effectively answer the questions and in-turn deliver those answers to the client some skills are needed. I only want to add three requirements to Pam's list.

    1. Are you organized?
    2. Are you a planner?
    3. Can you demonstrate the first two questions?

    For our own plug: We are based in Minneapolis, Cochabamba, Mexico City, and Ahmedabad. We have REAL offices in each of these cities staffed by REAL Wagento folks who care passionately about their jobs. We are hiring in all of our locations.

    Space 48's Article Excerpt

    The complete article is again linked here Now the real requirements

    You get your kicks out of a fast-paced environment, and I don’t mean disorganised, I mean busy!

    You absorb pressure like a sponge. I don’t mean you’re a punch bag for clients, I mean you can handle it, it’s all in a day’s work. If you hadn’t chosen a role in project management, you’d be a high-flier in the UN.

    Problems, you love problems, well you love solving them. That doesn’t mean its nothing but problems, but lets not kid ourselves they do happen but you can deal with them. That doesn’t mean you don’t bitch and rant getting to the resolution.

    You don’t believe in process for process sake but you know why it’s needed and how it can enable you.

    Pragmatism is your middle name, you strive to make clients happy but also care about making sure what you do is the right thing for them, not necessarily what they want.

    You’ve worked for a software development agency (not digital). You’ve ideally worked in eCommerce with at least 1 of the top 10 enterprise platforms, eg Magento, Websphere, ATG, Hybris, Demandware.

    You’ll be working in a supportive environment with an experienced team who love what they do. eCommerce is not for the faint-hearted but it is hugely rewarding.

    We’re based in Warrington at the moment and on schedule to open a new office in Manchester end of Q1 2017 where you will then be based.

    The salary matches our expectations and is highly competitive for the right candidate.

    I am linking to some other helpful articles about Project Management Best Practices


    Please give me your feedback:

    Twitter Linkedin

  • The Client



    Please read the previous post here Things Change to get context

    Let’s briefly look at what the typical client expects at the end of any project. (This is not meant to be a comprehensive list but a summary of the basic items a customer expects. If you think something should be there please comment on this post. I am always looking for feedback.)

    1. They would like what they like. This may or may not be defined at the start of a project.
    2. They want to know how much it will cost. This almost always must be defined at the start of a project.
    3. The cost has a max. This is ALWAYS true with everyone.
    4. They would like to know when it will be done, but unlike cost, when it will be done may or many not be as important.

    Like what you like but what is it like?

    If everything was a “Yes” and “No” projects would be simple. If there wasn’t complexity and, more importantly, subjectivity, projects would be easy to plan and deliver. The problem is the following:

    Client: “Dear Agency, I would like my website to look like” Agency: “Ok we will model some designs to make it look similar to” Client: “Please tell me how much it will cost to make it look exactly like MegaCorp and how long it will take.”

    If the agency is not careful they will start the project already failing. The “want” in a subjective environment is the hardest thing to attain and contains the greatest risk. The “want” is something that a young designer could deliver quickly or a seasoned designer may never deliver. The point is that it is very subjective. The “want” is the biggest risk because you don’t know what anyone really wants until you start working. The client may have many ideas in their head about what they want and those ideas change every time they look at the new website. For the agency, this means it is a moving target that can only be achieved once a design is locked down, agreed on by both sides, and signed off on.

    To further complicate things, if the design is something new and if the designer comes up with something revolutionary and fantastic, the inherent complexity of new design will most likely take longer and be more expensive. If they stray far from what Magento can do, the backend estimates for this design will be greatly inflated. This leads some clients to question why. It is the agency's responsibility to have a developer sign off on designs even before a client sees them. If you take a category page for example; The default category page does 80% of what most clients want. The designer may have great ideas but some of the functions they may suggest would require extending the basic functionality of Magento and thus add cost to the project.

    You can see how quickly the design portion of a project can get complicated and you can see why it is important to move from the subjective to the objective. If you have a design that shows what the look will be and then describes what the look will do then you will be able to gauge the effort of that feature much better than just “I like the page”.

    No Free Lunches

    I recently met with a large enterprise agency and they stated they build in 40% risk to a fixed bid project. In fact, if any agency is not building in some risk then they are providing a disservice to their team as well as their client. The time and materials model works the best if there is a broad budget of what is trying to be accomplished. The fixed bid is a myth and what fixed bid means is the following: I have a bunch or requirements that will never change and I will not want to add anything over the next 12-16 weeks. I have never had a software project where nothing changed. This is the reason that fixed bids are full of risk and that risk is built in. I will stress, if you are a client and reading this, don’t think the risk is something that you want to add. The risk is for something that wasn’t known but could have been, should have been or, at some point in the project, became known.

    Max Headroom

    The idea of a broad budget is, in my opinion, the best way to approach a project. You can section off specific buckets of work and then scope out that work. The risk is balanced over different areas and it will allow the client to see where changes happened and how they impact the project. Design, Development, DevOps, and Data are all big buckets that can sit at the top of your SOW. These buckets can be pared down into smaller segments which will further reduce the risk.

    The Final Countdown

    Of course, everyone wants to know when their project will be done. I think this is the most overlooked area. Once you have hours estimated you can by definition plan on when those hours can be worked. From this, you can plan on how long it will take to carry out the work. Finally, you can build in the time that tickets go back and forth with clients. Once you have that formula you can come up with a launch date. The launch date will help to hold everyone accountable. It not only holds the agency accountable, but it also holds the client accountable to what they need to complete.

    Tomorrow, tomorrow, I’ll finish tomorrow

    As we just discussed, the “when” can easily be estimated and the more you report the “when” the better everyone understands what is holding things up. So the final launch date is set, we are moving towards a date and the client decides they want to wait.

    …and wait

    …and wait

    What do you do?

    Next week we will look at the Agency perspective and see how the waiting and other things can be resolved.

  • Things Change - The Fix Bid Project


    Things Change

    by Brent W. Peterson Directory of Customer Experience.

    A continuation of my Customer Experience series. At the end of the day, the client wants to have their website completed in the way THEY want it. The trick is when you start your project things change. Things change and whoever starts a project as a fixed bid and will hope to come to the end of a project with what they started is only fooling themselves. Things change from the client perspective and things change from the agency perspective. The bottom line is that these changes will affect your project and the sooner you can wrap your head around this concept the more successful your project will be.

    The Basics

    Client wants something -> Agency delivers something

    The success or failure of a project resides in the middle of these two things. What we can do now is to continue to break down the high-level items in any project. From these items we can ask questions about what is important to getting from A to B. How we navigate that road and how we report where we are and the road blocks involved will determine the success of the project. Let me add that the length of the road and the amount of work that needs to go down the road will also contribute to the success of the project. If the project is projected to last 2 years there is a much higher probability of failure than a project that will last only 2 weeks. The ratio of work to time is an important number to look at. The risk of a lot of work and a short amount of time is that something has to be given up. One cannot simply deliver everything in a given time when it is impossible to do everything in that time.

    Let's break down the project at a high level

    • Client wants something
    • Client communicates to agency what they want
    • Agency digests what they want to communicates back to client what they will do and how long it will take to do it.

    The “want” in a project is not always 100% to everyone. The “want” is sometimes all determined at the beginning but most likely wants will trickle out during the project. This is the biggest reason why Agile is the best approach for project management. So the next question is “How do I translate what the client wants into what we are going to do?” This communication is the key to the success of the start of the project, but continued communication and a partnership point of view is how the project will finish successfully.

    The how long it takes to do it is a number that will cause great contention later in the project. Why? Because what the client expects will be done may be different than what the Agency thinks they want. To further complicate things we have time that is lost because people need to eat and sleep and we have weekends and vacation. So 80 hours of work doesn’t necessarily mean it will be done in two weeks. It is the responsibility of the agency to communicate that the time to complete the 80 hours will be compounded by the fact that there may be a time that work goes through Q/A and the Q/A team will need time to review and look at tickets. (This is just an example, but there are many other factors that will contribute to this time) What we do know is that we can come up with an average of how long it takes to complete 40 hours of work. An example is the following:

    40 hours = 5 man days. The 5 man days will take unto 15 days to complete because each item that makes up those 8 hours of daily work must be reviewed by a project manager, worked on by a developer, Q/A by a technician, code pushed around by a DevOp and reviewed by the client. All these steps assume that everyone will take them in serial order. The client can argue that the agency can simply put more developers on a project. So theoretically a 40-hour job could be done by 5 people in one day. This assumes that the client also has enough people to review the work being done in that day and that the work CAN be done in parallel. It is at this point that the agency has the responsibility to communicate truthfully to the client that something CAN’T be done in the timeframe the client requests.

    Next week we will dive into the Client.

  • The Wagento Approach to Customer Experience

    customer-experience The Customer Experience

    Wagento’s Approach to Customer Experience

    by Brent W. Peterson Directory of Customer Experience.

    To start off this will be a series of blog posts that will last a number of weeks. The title is not meant in anyway to say this post is the end result of all our customer experience!

    To this we have learned our first lesson. Aligning Expecations. When I first published this I was told that the complete guide surly can't be a couple of paragraphs! So to help everyone understand what I am doing and what I am trying to accomplish we will walk through a number of stages in the experience and then dig deeper to see what we can learn. Along the way I would be eager to hear your feedback. This will help to shape our experience together so it is not just Brent's experience but the experience as a community. I did notice I say this at the end of this post, but some of you may stop right now and not read any farther.

    For the last couple of years I have been fixated on making the customer experience better and more specifically making it better within a project and with our project managers. It started back in 2014 when I gave a presentation at Meet Magento NYC about the idea of an open source agency. This theory looked at the idea that we share our knowledge on open source software, then why can’t we share our knowledge with our process for running an agency. Were there so many things that were proprietary that it meant we couldn’t talk about these things? If you would like to see my talk in Germany here it is:

    The talk lead me to start asking questions of our own process and my next presentation was wrapped around the “Awkward Conversation.”  When I gave this presentation at MagentoLive Germany I thought I would address it to merchants who would like a better understanding of how a developer or agency interacted with them. If the success of a topic can be measured on questions asked, my topic was successful. In fact, my wife was sitting in the audience and a merchant leaned over and mentioned that he had not thought about this but this is very helpful. What was more surprising was that the majority of the questions from the audience came from developers.

    For Magento Imagine in 2015 I submitted the same idea with a slight twist. I would focus equally on the merchant and the agency. Giving each equal weight. With this balanced approach, I thought I could speak to both the merchant and the developer/agency and hopefully raise some ideas that would resonate to everyone in the audience. After this presentation nearly all the questions came from developers. This could be the audience that I was put in, but what it told me is that there is a disconnect in what we as developers or agency leaders think customers want and what the customer wants.

    Over the next weeks, I will outline my thoughts on Customer experience within a project.   I would like to foster an open conversation on what works and what doesn't work. You can comment freely on the post or email me privately.

  • The Project Managers Dream

    Wagento Magento

    Over the last couple of years I have been speaking in public about client expectations. In doing this I have always pushed our internal team to work with clients and to communicate expectations as often as possible. I recently had a long drawn out conversation with one of our project managers on the fundamentals of project management and we spent a lot of time debating small points, edge cases and things that may or may not happen. The really productive part came as I asked more and more questions.
    Eventually I came up with the following three fundamentals so that we can respond to a client at anytime: (I am very interested in your feedback)

    1. What work we are doing and know about? (The time to complete items in a backlog)
    2. What work are we waiting for more info and can't estimate or that we can't answer but can report to the client that we know about this item?
    3. What work don't we know about and therefore can't estimate? (Magic things that only Leprechauns or Fairies can answer)

    On any project and anytime we should be able to address these three questions and report to the client. In addition we can report these three conditions to the client on a weekly basis so everyone is in tune with the status of the project. I believe these are the three main items that can always be addressed.

    Are there more?

    What have others done to make sure they can answer questions about a project at anytime?

    What are addition KPI's* that could be addressed at the highest level?

    *Key Performance Indicator

8 Item(s)