I recently interviewed a candidate for a project manager role. One of the questions I had revolved around stakeholder management. We sidetracked a bit and I asked her whether she had experience with steering committees and stakeholders that are driving the project to a failure.
She mentioned that she did not have the experience but had a colleague going mental. Guess what type of project it was?
Yes, a Microsoft SharePoint implementation.
The other type of project could have been a CRM project. Those projects seem to suffer also from too many stakeholders without clear ownership.
My advice for those projects are in summary to my earlier post:
Don't let the steering committee drive requirements or design
They simply do not have the required detail knowledge of the tool and the day to day operational use. Though they might think they know it because in the end they will use it as well, reality is they use these systems only sporadically and are insufficiently in touch with how their people will use it on a day to day basis.
Find the real subject matter experts
Every organization has a few of them. The have a good oversight of the detailed processes in the organization. Realistic people with two feet on the ground. Try to find a small group of those to develop requirements and design.
Don't let consultants take over
They will tell you to use columns in stead of folders. The truth is that the technology is not ready for it and the users will not be able to make this conceptual switch. The users are already confronted with many other changes, so keep things as familiar as possible.
Keep things as vanilla as possible for the first implementation
Over engineered configurations and customizations can only do damage and are difficult to remove. It is always easier to add them afterwards.
Focus on usability
No matter how great demos and pilots were, there are always these features that the vendor did not implement in an easy to use way. For example granting access to sites and files to colleagues in SharePoint 2007 is not something easily picked up by users. And don't give this responsibility to the managers but give it other users in the team who are better available and will use the system intensively. Did you review how to move a file from an MS Outlook attachment into SharePoint? Little practical things that are easily overlooked but are crucial for the day to day usability.
Run a thorough pilot with real end users
At one moment in time, a project team and people intensively involved in the project will pick up the technology easier and quicker. They are motivated and will have a different attitude. It is good to create champions in the organisation, but you need to make sure you pick up feedback from people who will resist more and will not pick up the technology as quickly as champions.
Be ready for the next phase
It won't go smoothly, so prepare for the next phase, upgrade and probably further simplification. SharePoint requires quite a bit of processing, as well on the server side as the PC side. So expect that some investments might need to be done here as well.
Are computers getting smarter than humans?
Recently our virtual management software that has some intellegent rules decided to be a bit smarter then we had expected. The result was a tempoary reduction in performance for some of our servers. As a consequence one of my colleagues got a bit upset and responded with the email text below.
You wonder who demonstrated more intelligence :)
This is wicked ..like Tron and stuff or 2001 ...DRS is like Hal he ished the commands to doubling down on the vspehere 1 gangstas then there was an evacuation of the tubes..
i love tech man ..(though some of the below sentences sound like my prostate issues)
i love internets ...whoop whoop.
Tech + Beer (non-virtual beer i want the physical stuff) + Pings = NodeloveBieber
Some computers seam to be beat us: http://www-03.ibm.com/press/us/en/presskit/27297.wss
You wonder who demonstrated more intelligence :)
This is wicked ..like Tron and stuff or 2001 ...DRS is like Hal he ished the commands to doubling down on the vspehere 1 gangstas then there was an evacuation of the tubes..
i love tech man ..(though some of the below sentences sound like my prostate issues)
i love internets ...whoop whoop.
Tech + Beer (non-virtual beer i want the physical stuff) + Pings = NodeloveBieber
Some computers seam to be beat us: http://www-03.ibm.com/press/us/en/presskit/27297.wss
Business requirements are discretionary
Business requirements are not set in stone. We know that they can change during a project but quite often they are a personal preference of stakeholders. You would expect that they are logically derived from the business processes. But often the definition of the business processes allow for much freedom while there is much debate about what the right process for the organisation is.
Every employee in every organization will have complained at some stage of their career about inefficiencies in their organisation and asked themselves why "they" could not have designed this better. If you take over a job from someone else, you are bound to do things in a different way than your predecessor. And the same thing applies to managers. When a new manager comes in, he will guaranteed change the operations to improve it.
Business processes change as regular as the weather, wether it be small tweaks or major overhauls of the business.
You hope that changes of the business processes are to be improvements. In essence you still have the same business objectives but you just want to do things better. Every organisation will constantly go through these changes. However, sometimes you wonder whether these are actually improvements and that it is just a change for change sake. Sometimes when there are disagreements, you feel that either way could be right and that it does not really matter.
For example, our organisation has chosen not to use purchase orders. We have some other mechanisms in place to cater for the authorisation of purchases. The consequence is that we have an invoice processing system where we approve the payments of invoices. There are however a few strong proponents for a purchase order system and with such a system we probably would not have needed the invoice processing system. Without going into the details, there are good arguments for either approach. But given that you have made choices in the past, it is difficult to change later.
In the past I was involved in the development of the various incarnations of the website of our consultancy company. Of course there were as many opinions about the design, information architecture and content as there were people in our organization. The ones that were directly involved with the building and writing of the texts got their way most of the time.
When we implemented SharePoint for our document management, there were also as many opinions of how this should be done as there were people involved in the project. Specifically because we as IT people would also be using the system, we considered ourselves subject matter experts and tried to drive the requirements and design as much as possible. We probably should have tried harder.
These examples just indicate that there is not one set of right business requirements and that they often easily can be interchanged. They can easily be changed and they do. And that is why I prefer to look at the the data first before I build new systems.
I was educated to do an information analysis as one of the first tasks to come to a new system.
This does not mean that processes are ignored but it gives a different perspective. Actually, modeling the processes would be the second step before going into requirements. These first two steps are what I call the real business analysis (see this post) and also serve the purpose of looking for ways to improve the business. Doing an information analysis and business process analysis upfront, gives better insight in the data involved and how and when it is used. It however implies that this phase must be driven by the business owner.
These days we usually start with business requirements which will result in a system design and a data model. It means that a overview of the data only comes much later to light in the process of custom development. However before you would come to that, you will have made decisions about off-the-shelf solutions versus custom development. The problem is that business owners usually come with an idea of a solution and you just need to write down the requirements. The consequence is that the broader context is ignored.
The data structures in an organisation are much more stable over time than the processes and the required application functionality. When you can come to a clear definition of the required information and preferably through a single access layer, it is easier to build varying application functionality on top of this.
If you drive your application architectures from individual requirements, you will have a higher risk that this will lead to more fragmented data structures which will mean that it is more complex and expensive to change the requirements later. For example you will be more inclined to come to a series of standalone off-the-shelf applications where there is no data flow between those applications. At first sight it might seem a cost efficient solution but when the requirements change, you might have to build costly integration software or you might have to redo some of the work. And you will probably run into cases that the actual data cannot be linked between the systems.
And then I like to come back to what I mentioned before. You will define your processes depending on the current situation and depending on systems already in place.
That is one of the challenges of IT. When we implement business systems, we have direct influence over the business processes and the business requirements. If you do it right, you can participate in improvement of the business and that can go all the way to assisting with the business strategy. But it is also a cause of conflict and confusion about the role of IT within an organisation.
Every employee in every organization will have complained at some stage of their career about inefficiencies in their organisation and asked themselves why "they" could not have designed this better. If you take over a job from someone else, you are bound to do things in a different way than your predecessor. And the same thing applies to managers. When a new manager comes in, he will guaranteed change the operations to improve it.
Business processes change as regular as the weather, wether it be small tweaks or major overhauls of the business.
You hope that changes of the business processes are to be improvements. In essence you still have the same business objectives but you just want to do things better. Every organisation will constantly go through these changes. However, sometimes you wonder whether these are actually improvements and that it is just a change for change sake. Sometimes when there are disagreements, you feel that either way could be right and that it does not really matter.
For example, our organisation has chosen not to use purchase orders. We have some other mechanisms in place to cater for the authorisation of purchases. The consequence is that we have an invoice processing system where we approve the payments of invoices. There are however a few strong proponents for a purchase order system and with such a system we probably would not have needed the invoice processing system. Without going into the details, there are good arguments for either approach. But given that you have made choices in the past, it is difficult to change later.
In the past I was involved in the development of the various incarnations of the website of our consultancy company. Of course there were as many opinions about the design, information architecture and content as there were people in our organization. The ones that were directly involved with the building and writing of the texts got their way most of the time.
When we implemented SharePoint for our document management, there were also as many opinions of how this should be done as there were people involved in the project. Specifically because we as IT people would also be using the system, we considered ourselves subject matter experts and tried to drive the requirements and design as much as possible. We probably should have tried harder.
These examples just indicate that there is not one set of right business requirements and that they often easily can be interchanged. They can easily be changed and they do. And that is why I prefer to look at the the data first before I build new systems.
I was educated to do an information analysis as one of the first tasks to come to a new system.
This does not mean that processes are ignored but it gives a different perspective. Actually, modeling the processes would be the second step before going into requirements. These first two steps are what I call the real business analysis (see this post) and also serve the purpose of looking for ways to improve the business. Doing an information analysis and business process analysis upfront, gives better insight in the data involved and how and when it is used. It however implies that this phase must be driven by the business owner.
These days we usually start with business requirements which will result in a system design and a data model. It means that a overview of the data only comes much later to light in the process of custom development. However before you would come to that, you will have made decisions about off-the-shelf solutions versus custom development. The problem is that business owners usually come with an idea of a solution and you just need to write down the requirements. The consequence is that the broader context is ignored.
The data structures in an organisation are much more stable over time than the processes and the required application functionality. When you can come to a clear definition of the required information and preferably through a single access layer, it is easier to build varying application functionality on top of this.
If you drive your application architectures from individual requirements, you will have a higher risk that this will lead to more fragmented data structures which will mean that it is more complex and expensive to change the requirements later. For example you will be more inclined to come to a series of standalone off-the-shelf applications where there is no data flow between those applications. At first sight it might seem a cost efficient solution but when the requirements change, you might have to build costly integration software or you might have to redo some of the work. And you will probably run into cases that the actual data cannot be linked between the systems.
And then I like to come back to what I mentioned before. You will define your processes depending on the current situation and depending on systems already in place.
That is one of the challenges of IT. When we implement business systems, we have direct influence over the business processes and the business requirements. If you do it right, you can participate in improvement of the business and that can go all the way to assisting with the business strategy. But it is also a cause of conflict and confusion about the role of IT within an organisation.
Subscribe to:
Posts (Atom)