One of most vexing issues to handle as an architect / designer is objections raised as the final product is delivered. It is a common occurrence when presenting the finalised design to people/stakeholders who have not engaged during the design process. Often because the design team didn’t know about them or because the individuals were “too busy” to engage during the requirements gathering or thought the project didn’t seem important to them during the initial engagement.
These people can derail the project simply by throwing objections on the table that were not known, foreseen or expected. How can you ? You aren’t aware of their relation to the solution, or their requirements. I feel that there are two common reasons that this happens. The most common is that companies have reduced their internal training programs and many people are not efficiently able to manage their time or adequately delegate to cover all the available work.
The second is lack of competence where a manager has a poor understanding of the company products or process. This means that they fail to understand the impact of an IT project on them until the final solution is already completed. Many managers believe that “everything is a process” and “product knowledge” is not needed.
Not much you can do about either of these in a waterfall development project process. I can & do spend a lot of time ensuring that I manage stakeholders in my projects but it takes a lot of time to locate people in an organisation, qualify their needs & relationship to the project. That time is always better spent on solving the design problems instead of having “chats” with various people in an organisation.
Without a doubt, the lack of IT competency among business managers remains a serious problem. Many managers simply will not discuss, engage or take the time to understand an IT solution. If you have ever been confronted by an executive demanding that you “explain the solution in business terms” you have experienced the problem.
I’ve become a strong proponent of Agile processes for building infrastructure. By delivering incremental change and progressive deployments, I’m now finding that I can enforce management engagement without wasting time looking for them. Simply because the changes are happening immediately and it is more obvious what is happening.
There are no formal design reviews, so there are no huge decision points. Instead, we can make the decisions fluid. Since we iterate every day and never have dumb-ass presentations, we don’t run into major disagreements. – Jony Ive on the design process at Apple -from the book “Steve Jobs” – Chapter 26.
Major changes using waterfall project methodologies lead to communication failures in many companies. People can, and do, ignore projects during the development phase because “its not a problem”. And this is where ITIL & ITSM process completely fails – it assumes that service owners are competent people who understand their technology. This is rarely true.
Incremental change leads to engagement and wider discussion. That is just one of the benefits of Agile & Scrum delivery.