Today I’m going to dispel some myths and share some insights about IT Project Management which we’ve learned on large scale eCommerce implementations :-)
Business backend
Companies may have many different motivations to start eCommerce – from branding and marketing to a typical revenue-based approach. From projects I was involved in, I can say that successful eCommerce motivation is always based on numbers and ROI; it’s part of your core business and should be treated as such.
I mean that you have to have your management board involved because eCommerce operations almost always require many cross-company changes; pricing model changes are a good example; franchise partner conflicts; click&collect and other features based on the ROPO effect are another one.
eShops backed only by marketing or any other single dept. without full-company support rarely achieve success because it requires changes to many processes:
- supply chain, logistics, and returns
- product management
- IT system integrations
Almost all successful eStore projects I’ve seen started with a written eBusiness strategy which consists of P&L (to ensure we don’t over-invest as well!), goals, and an action plan. Almost all of those successful companies hired an eCommerce Manager and a CTO/technical consultant to cooperate with external vendors and build in-house knowledge.
Communication
Project management is not only about delivering tasks and meeting deadlines. It’s about communication. In large scale enterprises, it’s important to keep all parties, and all departments, involved and informed.
RACI (Responsibility Assignment Matrix) is a good tool to start with; It’s where you put all stakeholders and figure out who makes the decisions in each area and who should be informed about particular decisions.
Most common example? The GO-LIVE date is usually set-up by the Business Owner on a high level, but then particular change orders from the Product Owner can extend the scope and change the date as well as the budget. Not keeping the Business Owner informed about such changes is extremely dangerous.
Goals
Your stakeholders’ needs will be contradictory and can vary in time – collect them, try to find a consensus, design and show them something easily understandable. You have to take some time to understand your stakeholders and their goals.
The Product Owner on the business side and the Project Manager on the IT side are the two to make the consensus happen. They should be a single point of contact on both sides – no matter if you’re working with an external IT vendor or an internal IT dept.
They should be translators and an exchange point of business needs and IT capabilities, establishing consensus among contractionary business reqs. and translating IT details into an understandable language of deadlines and budgets to help Business owners make the decision.
They should cooperate closely and on a daily basis; of course, engaging particular departments and specialists where it can speed-up communication but finally, each decision according to the project must be accepted by those two to meet the project goals.
Time and Materials
Like in business, in IT everything starts and ends with time and money. Starting an IT project, you have basically two budgeting options: Time and materials, and Fixed price.
Features of T&M:
- Ongoing demos / retro meetings
- Control over deadlines: deploy often / deploy early
- Typically you work in SCRUM or other Agile methodologies
- Full control over the project, features, and quality
- Clarity – pay only for hours spent on the project
- No UATs wars at the end of the project – overall quality
Features of Fixed price:
- Months with no feedback from the end users
- Waterfall methodologies in use
- Specifications over quality
- Little to no communication
- UATs wars
Basically, T&M is the most chosen option nowadays and here’s why: it can be cheaper and provide you with better results than Fixed price. The key feature here is control over product and process. But as usual, with control comes responsibility.
Agile traps
Here you have some Agile traps.
First and foremost, you must always remember that your Business Owner is focused on budget and deadlines, not necessarily worrying about particular features a project will offer (or other details). You have to be careful, as the product owner, to deliver under budget and within deadlines – ideal projects don’t exist. Trying to build astonishing systems can be a never-ending story and, as is always the case, something that works is better than something that will work someday :)
It’s tempting to start the project fast without analysis but it can, for sure, lead you to go over budget (because doing so you don’t have a reference).
You must require key stakeholders to attend demo/retro meetings and daily meetings which are time-consuming. But control over the process and a healthy “trust but verify” rule is a key to success.
For sure, your Business Owner won’t be interested in such deep involvement – so keep him or her informed and never surprise them.
My experience is that Enterprises love Agile but expect projects to be conducted in Waterfall to stick to budgets and deadlines, and to not be too involved in the development process.
It can be mixed together:
- start with an analysis phase to estimate the overall budget (remember about buffers for changes)
don’t be too optimistic – try to catch the whole project at once
go along with the “Trust but verify” and “No surprises” rules
Budgeting
To get realistic, a budget starts with analysis and with a detailed brief describing all the features and business goals for the projects.
The pricing you got from the agency Sales Rep rarely equals the final budget because of challenges and changes along the way, so it’s good to have some buffers in mind when planning the scope.
The final budget can be created after the analysis phase and business process description, user stories, mockups, integrations (always a risky part).
Never start development without analysis if you are required to stick to the budget and/or deadline. Involve your team in the analysis process.
To maintain the budget – in the case of any ongoing challenges – I suggest prioritizing requirements using MoSCoW (MUST, SHOULD, COULD, WON’T). It’s easy then to reduce project scope to meet the global goals.
Remember – the Business Owner is Focused on budget and deadline. Always!
Priorities
To go along with Agile and keep to the budget, you can use MoSCoW prioritization for budgeting.
In such cases, many IT companies suggest the following rule: MUST = 60% of budget; SHOULD + COULD = 40% ,
MUST is guaranteed to be delivered but in the case of challenges SHOULD and COULD features can be cut off to make a buffer.
Check if budget is realistic:
- communication + PM (about 20% of development time),
- time needed for tests (20% of development) + fixes,
- buffer for risky parts (eg. 30% buffer on integrations),
- buffer for change orders (it depends, 20-30%?),
- every time you put business/end users in front of the system, there will be change orders :)
Monitor project progress weekly:
- time spent / total time;
- time spent / time estimated;
- team pace;
- working hours until the end of the project
Requirements consensus
There is no “single stakeholder” at your company. Requirements consensus sometimes needs an offline processes adoption (common minimal denominator),
You have to organize a few all-hands meetings to make the reqs. consensus happen between departments. It’s good to engage end users early – during the analysis phase, and into tests.
People often don’t feel comfortable with IT specifications. They understand what they get, what they can see and test. This is why mockups work perfectly. But this is also the reason for the pilot-phase. To make it happen, select early adopters from your company units … and plan some time to implement changes after it.
Rule of thumb? Late changes often result in the budget overrun.
Track the progress
In SCRUM we try to map the entire backlog to sprints until the end of the project using JIRA.
I’m not a fan of the Nightmarish MS Project documents but of course, you can use it. It’s extremely hard to keep an MS project schedule up to date.
In addition to JIRA, we usually create a “Project Knowledge” document using Google docs; it contains:
- Schedule,
- Resources + availability,
- Open risks registry,
- Open Issues registry,
- RAG light reports
The goal here is to keep everyone on one page and keep it easy to understand. Open risks and issues registers are for business decisions. RAG Light reports – street light reports – are for the business owner: what can surprise me? What to expect?
If you cooperate with a few vendors and between a few depts, I suggest arranging weekly or bi-weekly steering committee meetings to present the Project Knowledge.
Here we have something about how SCRUM works. Daily meetings are key to success if you have a team greater than two people. But the meetings are for the team. They are not for business stakeholders – involving them can be a waste of time for both sides.
The Product Owner, Project Manager, and the team are those who should be there to discuss details of the tasks and challenges.
Then Retro+Demo meetings (once per sprint) are for business (AND technical) members, to discuss things understandable for the business; showing the demo and catching up with the team giving the tech guys direct feedback.
To not regress, it’s good to follow acceptance criteria (described in each JIRA task) and accept each particular sprint. It shortens up the UATs. But still – UAT’s after sprints are a mistake. There can be some minor bugs present and should be fixed after next sprint (or at the end of the project).
If you need business people’s consultancy, remember they probably have a lot of things to do and book their time in the very beginning of the sprint.
QA
A few words about UATs (User Acceptance Tests). Ongoing tests are focused on particular issues/tickets. So UAT’s are important to catch the bugs from the end users’ perspective. It’s easy to forget about some “minor” technical issues which can block some operations, like missing fields or columns. Easy to fix, but hard to figure out during the specification phase.
UATs should be focused on overall business processes.
Remember that not all business users are equally tolerant of issues; Invite testers carefully to avoid shooting yourself in the foot.
It’s reasonable to create test scenarios for key use cases/business processes first, to make sure we don’t miss any important business path.
It is often okay to have 100-300 bugs after UATs.
Launch
Product launch is one of the most stressful and risky moments during the project; It cannot be repeated.
The key is to Plan everything; create:
- Plan A,
- Plan B,
- Plan C :-)?
Plan DAY-0 should be planned with an hourly schedule,
Check twice: What can go wrong?
A schedule with no surprises – that’s the key. From my experience, a launching schedule should work like this:
- 2 weeks for UATs,
- 2-3 weeks for fixes,
- 2 weeks for re-tests,
- Code Freeze period,
- 3-4 weeks for Pilot phase,
- GO LIVE!
Published June 13, 2018
