Avoid common pitfalls during product design and creation - learn from our own experience.
There are several process systems that allow one to perform Information Architecture. (Hyperlinks available below.) Similar processes are used for Project Management, Product Management, Change Management, and so on. Therefore, some of the steps outlined below may seem familiar if not overlapping other processes. It is up to your company to discover which process separation works best.
The outline below will not suffice to run a company. You will need to add things like marketing, advertising, sales and contracting, human resources, support and aftercare, webcare, etcetera. This article merely focuses on Information Architecture. We base this on 15 years of professional experience.
The following steps can be used in any product development; they aren't specific to software development.
Your objective is to solve their problem, so it suits you to understand what makes them tick. What is their objective? Who are their customers, if any? What products or services does your client provide, if any? How much do they know about your work? How much do you know about theirs?
Traditionally, we would catch a client organisation in an organogram. The additional info can be expressed in a mindmap.
Who benefits from the project? Who is allowed to make decisions on budget, functionality, and deadlines? To whom do you report? Who pays you? Who is going to judge your report? Who will be using your solution? Testing it? Training the users? If third parties are involved in connecting information systems, who are they?
What is the objective of any of these parties, both within and outside of this project? What are their expectations?
The answers to these questions will help you write a report and develop a solution fitting the project. You will find that sometimes, your direct contact's agenda differs from their or your manager's. Sometimes the testers and trainers target a different objective than your client or your manager. You need to recognise this if you care to avoid getting caught in the cross-fire.
We can use a mindmap to draft an overview and connect relationships. However, stakeholders need to be listed in our report. A mindmap may not be suitable. We can rework part of this info as a simple table, specifying each stakeholder by name, function, and responsibility, grouping them by organisation. Each stakeholder's objectives can be worded in prose later on, to create a context for the expected functionality and architecture.
Sometimes you are the technical consultant, sometimes you are the interaction and functional designer, sometimes you are the test planner, sometimes you are the technical project manager, sometimes you are a programmer or tester. Whatever your place, figure out to whom you report - who are your colleagues, and for who do you carry responsibility?
If you are expected to create a cost estimate, it is essential that you understand your place in the team. Who else is providing a cost estimate? Who is overseeing the project to ensure all estimates get made and summized? When is your estimate due for delivery? (It may depend on your project management method.)
Before we get ourselves caught in details, we want to set a domain for our project. It's imperative that we reword what we heard from our clients and stakeholders during moments 1 and 2, using our own words. Having this checked by our client and stakeholders allows everyone to recognise intentions and errors early on, when it's still easily corrected or accredited.
Do not wait with getting this back to your client and corrected until you've finalised your report, or worse, created an estimate and a functional design: you'll be too late and you'll have invested too much time and money to change core assumptions.
Outlining the problem domain will also help colleagues and successors in case you get reassigned, fall ill, or switch employers.
What systems, procedures, organisations, third parties, technologies, etc. will the solution touch, require, implement, support, depend on, and why? What project management method seems the most helpful?
If doubting a choice between options, make that doubt part of a future discovery within the same project and inform the client.
Again, this understanding is essential before diving into a functional outline and a cost estimate. And just like with the problem domain, outlining the solution scope will help colleagues and successors in case you get reassigned, fall ill, or switch employers.
Along the way, it is possible that both the domain and the scope change. That is OK, as long as the budget-functionality-deadline-trio isn't fixed. If all 3 are fixed, both the domain and the scope must be frozen as well. Either way, now is the time to make the previous effor count, and get a signature on a work order.
Coming back to the trio of budget-functionality-deadline: if any of these changes along the project, the others are affected accordingly. For example: if the client wants a first go-live next week, the amount of functionality present necessarily is limited. Equally, if the client suddenly requires different or more functionality, this most likely will impact both the budget and the deadline.
Any client and manager who dealt with any product development before, understands this. This is not specific to software development. They also understand trying to get more for the same price, so don't be surprised when clients and managers try to take advantage of your good intentions: it's all about the money.
More to come!
The outline below will not suffice to run a company. You will need to add things like marketing, advertising, sales and contracting, human resources, support and aftercare, webcare, etcetera. This article merely focuses on Information Architecture. We base this on 15 years of professional experience.
Reconnaissance
The following steps can be used in any product development; they aren't specific to software development.
1. Get to know your client
Your objective is to solve their problem, so it suits you to understand what makes them tick. What is their objective? Who are their customers, if any? What products or services does your client provide, if any? How much do they know about your work? How much do you know about theirs?
Traditionally, we would catch a client organisation in an organogram. The additional info can be expressed in a mindmap.
2. Get to know the project stakeholders
Who benefits from the project? Who is allowed to make decisions on budget, functionality, and deadlines? To whom do you report? Who pays you? Who is going to judge your report? Who will be using your solution? Testing it? Training the users? If third parties are involved in connecting information systems, who are they?
What is the objective of any of these parties, both within and outside of this project? What are their expectations?
The answers to these questions will help you write a report and develop a solution fitting the project. You will find that sometimes, your direct contact's agenda differs from their or your manager's. Sometimes the testers and trainers target a different objective than your client or your manager. You need to recognise this if you care to avoid getting caught in the cross-fire.
We can use a mindmap to draft an overview and connect relationships. However, stakeholders need to be listed in our report. A mindmap may not be suitable. We can rework part of this info as a simple table, specifying each stakeholder by name, function, and responsibility, grouping them by organisation. Each stakeholder's objectives can be worded in prose later on, to create a context for the expected functionality and architecture.
3. Identify your place in the project process
Sometimes you are the technical consultant, sometimes you are the interaction and functional designer, sometimes you are the test planner, sometimes you are the technical project manager, sometimes you are a programmer or tester. Whatever your place, figure out to whom you report - who are your colleagues, and for who do you carry responsibility?
If you are expected to create a cost estimate, it is essential that you understand your place in the team. Who else is providing a cost estimate? Who is overseeing the project to ensure all estimates get made and summized? When is your estimate due for delivery? (It may depend on your project management method.)
4. Outline a rough draught of the problem domain, and check that with the client.
Before we get ourselves caught in details, we want to set a domain for our project. It's imperative that we reword what we heard from our clients and stakeholders during moments 1 and 2, using our own words. Having this checked by our client and stakeholders allows everyone to recognise intentions and errors early on, when it's still easily corrected or accredited.
Do not wait with getting this back to your client and corrected until you've finalised your report, or worse, created an estimate and a functional design: you'll be too late and you'll have invested too much time and money to change core assumptions.
Outlining the problem domain will also help colleagues and successors in case you get reassigned, fall ill, or switch employers.
5. Outline the solution scope, and check that with the client.
What systems, procedures, organisations, third parties, technologies, etc. will the solution touch, require, implement, support, depend on, and why? What project management method seems the most helpful?
If doubting a choice between options, make that doubt part of a future discovery within the same project and inform the client.
Again, this understanding is essential before diving into a functional outline and a cost estimate. And just like with the problem domain, outlining the solution scope will help colleagues and successors in case you get reassigned, fall ill, or switch employers.
6. Milestone: require a signed agreement from the client.
Along the way, it is possible that both the domain and the scope change. That is OK, as long as the budget-functionality-deadline-trio isn't fixed. If all 3 are fixed, both the domain and the scope must be frozen as well. Either way, now is the time to make the previous effor count, and get a signature on a work order.
Coming back to the trio of budget-functionality-deadline: if any of these changes along the project, the others are affected accordingly. For example: if the client wants a first go-live next week, the amount of functionality present necessarily is limited. Equally, if the client suddenly requires different or more functionality, this most likely will impact both the budget and the deadline.
Any client and manager who dealt with any product development before, understands this. This is not specific to software development. They also understand trying to get more for the same price, so don't be surprised when clients and managers try to take advantage of your good intentions: it's all about the money.
More to come!
Need problem solving?
Talk to me. Let's meet for coffee or over lunch. Mail me at “omegajunior at protonmail dot com”.
