Things to know, starting on a project
There is an urge to start contributing to a project as soon as possible after being assigned to it. You would want to present your best self forward and do all the right things based on your experience. What distinguishes you from the existing colleagues on the project is the context, knowledge, and a hang of things happening in the project.
To start adding value to the project as soon as possible, its good to get a good project overview.
Most of the Author’s professional projects have been software delivery projects with a flavor of technology consulting to it. The nature of the work is such that we (as a team) have to work with our clients on their problem statement (project). The team setup may vary based on the engagements. Sometimes we team up with some people of the clients as well.
The teams have mostly been cross-functional with roles like Software Developer, Quality Analyst, Business Analyst, User Experience(UX) Designer, User Interface(UI) Developer, Product Owner, and Leads of various roles.
Over the years, we have observed, learned (the hard way), and received insights into how to get up and running on a project.
Let us discuss the things teams should do, starting on a new project. Most of the things are equally applicable to the individual as well.
Logistics and Access
Know about the logistical aspects of the engagement. This can include information about the workspace location, access cards, onboarding processes, laptop & other hardware peripherals, access to Client facilities, stationary articles for daily work, access to communication channels like email and messaging apps, etc. Ideally, you should get this done within the first week or even before starting work at the client’s location. This will help you get rolling with the project related work as soon as possible.
Know Deliverables and Expectations
Direct Client Expectations
Know what Client expectations are from your team and the entire engagement. This may not be clear right from the start. You have to identify the expectations by asking questions, from their feedback and gestures in the initial phase of the engagement.
Some Clients use metrics to evaluate your work and project success. And this may very well differ from your definition of project success. Understand all these metrics. Work out a strategy to get the best of both the worlds. Choose the middle path.
Indirect Client Expectations
Apart from obvious and direct expectations of the engagement, there would be some which may not be apparent but are implicitly part of the evaluation. This would include punctuality, office hours, transparency, communication discipline, etc. They may not be directly related to your work output but does matter to the Clients more often than not. The tricky bit is that a lot of it is intangible and cannot be easily justified once under question.
People in leadership roles in the team should set and negotiate expectations with the Client early on to avoid misunderstanding later.
Another important thing that people may miss is to know their company’s expectations from the engagement. For example, do we want to create long term partnership with the Client or do we need to quickly fix things and move out or do we want to help them transform their ways of working.This will help us get into the engagement with the right mind set and build right relationships with the Client folks.
Deliverables
Highly focused and productive teams know their goals and expected outcomes well. It is important to know the problem statement the team will be working on and the deliverables to be produced.
A lot of teams fail to understand their roles and responsibilities as part of the larger project because they are not clear on their deliverables. As a result, the inter-team communication and coordination go for a toss.
It’s good to sync up and confirm with the Client on the expected deliverables once you a vague idea of it. Such acts are often appreciated. The reason being: you have taken up responsibility for your part of work; you bring more clarity to their overall understanding as well.
Roadmap and Milestones
Knowing the roadmap of the project gives a sense of direction you would go on to. Milestones on the roadmap would help you prioritize work better. Based on the milestones of other teams and their dependencies on your team, you can figure out what’s achievable and what’s not. Additionally, you can raise concerns about the overall plan.
Know the domain
This is one of the most important things to know as soon as you start on any project. Start collecting information on the domain of the project or if possible on the domain of the bigger entities of the organization. Know the vocabulary Clients use and how it maps to the actual systems.
Once you get a picture of the domain, understanding the problem statement becomes easy. You can ask better questions to the client.
Various clients have appreciated us on multiple occasions just because we were able to ask meaningful questions related to their business and surface up gaps in the overall understanding.
Domain knowledge will help you come up with better software architecture, designs, and code. For example, your domain knowledge can be applied in Object-Oriented Programming, which talks about representing classes as real-world entities. The code is readable and elegant with better domain modeling. Imagine that you have to work on a problem statement related to the e-commerce platform. Information about terms like SKU, fill rate, product order, order status, etc should be good to have.
Know the People and the Organizational Structure
Points of contacts
There is at least one person from the client who is responsible to bring you into the client workspace. This person is the go-to point of contact most of the time. However, there will be other people who you would need to seek help from time to time.
Know the IT assets people, know the infrastructure people, know people who can give you the necessary access to resources like source code, internal documents, communication channels, etc.
Know other teams and how you as a team are placed in the organization.
Its always good to know how a team’s activities and responsibilities are dependent on these points of contact. For example, if we are to set up CI pipelines for our work and we need help, we can always contact someone from infrastructure.
Not all the people from infrastructure can help you with what you need. Hence, knowing peoples’ roles is also beneficial.
Decision-makers and Power structure
All organizations have some sort of structure in which people are organized. These structures are loosely based on role, responsibility, department, authority, and influence.
In the scope of your work, identify all the Decision-Makers and Influencers. These are the people who make things happen. Anyone in between is just a proxy.
Tech Leads would mostly define coding conventions, programming languages, choice of frameworks. Solution Architects would influence system design and architecture. The features list is driven by the Product owner or a close confidant of the head of the Program.
All this knowledge can help you understand the status quo of the project, the project roadmap. This will help you influence and convince people about the right things to do.
Know the Project, processes, and practices
Know the existing business process
There are times when the client would be open to let us define the software development process and other times we have to follow their way. In the case of later, it’s helpful to get up to speed with the existing processes.
It may seem confusing and ambiguous at first glance. But the author has learned the hard way to understand the processes first and then recommend changes as is the case with Software Consultants.
Once you have understood the processes, you can raise concerns or synchronize with them. Processes like User story mapping, iteration planning, retrospectives, release management, issue tracking are some of the examples.
Show Work Progress and Updates
Based on the organization structure and set cadence, the client expects some sort of updates on your project work. Identify what are the tools and methods to convey your team’s work progress to the Client. Of course improvements to existing processes can happen once we have their better understanding.
Know IT Infrastructure
Identify all the environments in which the system is running. Typically people name them dev, SIT, staging, UAT, prod, etc. These vary across the clients, with prod and dev always being there. It’s always useful to get access to these environments and start understanding the underlying infrastructure and support systems.
Infrastructure typically would include application servers, database servers, network (intranet), CI system, version control system, etc.
Know IT security process
Information security is crucial for Clients. It is a good practice to know about standard security practices and follow them everywhere. Additionally, it is important to understand the security policies and practices of the Clients.
Most of the workplaces have security policies and guidelines available on the company portal. A lot of them do conduct tests and training programs to educate people about it.
Know the Tech-stack and software development practices
For an ongoing project, it would make sense to know all the technology frameworks, tools, programming languages, platforms used for the work.
Also, figure out the coding standards, programming conventions, code styling, branching strategy, code quality practices, etc for effective churn of the code.
Know your Dependencies
It may not be obvious, but project dependencies drastically affect your team’s throughput. Its always good to know what are the dependencies associated with our work.
For example, your team may depend on a security team for a library to complete a feature. Another example is your dependency on a QA team (believe me it still happens :|) to put the code in staging environment. Such dependencies will always constrain your team and affect better outcomes.
Having zero dependencies is not practical and possible. Sort out all the dependencies and mitigate risks associated with these dependencies.
In no way is this list complete. However, this will hopefully help you get ramped up on the project pretty well and quickly. The article discusses things to know and not much of how to know them. “How” part is highly subjective and situational. You can apply your experience or experiment with methods and practices to build new experiences.
All the things mentioned above would not be a responsibility of just an individual but of the team. Hence, having a highly aligned cross-functional team would help achieve these tasks relatively easily. Effective teams would distribute these tasks amongst team members and achieve the objectives much faster as well.
The Author would be happy to receive any suggestions, feedback and corrections on the article. Please share your experiences for community learning.
