October 2013 Entries
I had a meeting with a stakeholder who stated “I bet you wish I wasn’t in these meetings”. She said this because she kept changing what we thought the end product should look like. My reply was that it would be much worse if she came in at the end of the project and told us we had just built the wrong solution.
You have to take the time to get the requirements right. Be honest with all involved parties as to the amount of time it is taking to refine the requirements. The only thing worse than wrong requirements is a surprise in budget overages. If you give open visibility to your progress then management has the ability to shift priorities if needed.
In order to capture the best requirements use different approaches to help your stakeholders to articulate their needs. Use mock ups and matrix spread sheets to allow them to visualize and confirm that everyone has the same understanding. The goals isn’t to record every last detail, but to have the major landmarks identified so there are fewer surprises along the way.
Help the team members to understand that you all have the same goal. You want to create the best possible solution for the given business problem. If you do this everyone involved will do there best to outline a picture of what is to be built and you will be able to design an appropriate solution to fill those needs more easily.
It was 2001 when a project manager first put my job title as architect on a statement of work. A lot has changed over the last twelve years. The concepts around what an architect is has evolved. In the early days I would have said that they just rebranded the role of the system analyst. Now we have a multitude of architect titles: application, solution, IT, data, enterprise. Whatever the title the goals are the same. An architect takes the business needs and maps them to the solutions that are needed and at the same time works to ensure the quality of the solution and its maintainability.
One of the problems I see these days is that we are expecting every developer to have architect skills. That in itself is not a problem. This reduces the need for dedicated architects. Not every developer though is going to be able to step up to this level. Some are just good at solving small problems instead of thinking in the larger abstract.
Another problem is the accelerating speed and breadth of new technologies and products. For an architect to be good at his job he needs to spend large amounts of personal time studying just to stay relevant.
In the end I don’t think the main objectives of an architect has changed, just the level of commitment needed to stay of value to your company. Renew your commitment to your profession and keep delivering great solutions.
Just a small rant here. Today the Windows Phone 8 GDR2 update finally became available for Nokia handset users. Now I’m not sure that it is AT&T fault entirely that Samsung and HTC users got their updates two months ago and we are just finally seeing it. It may have something to do with the Nokia Amber update. But every Windows Phone update on AT&T from 7.1 on seems to have been delayed. How is it that the premiere Windows Phone carrier is always the last one to release updates?
Smart phone ecosystems are a partnership between the OS provider, the hardware manufacturer and the carriers. If any one of those partners does not hold up its responsibilities then everyone gets a black eye. The goal for all involved should be to release updates as early as possible with reasonable assurance of stability. This ensures the satisfaction of consumers and increases the likelihood of future sales.
From what I have seen so far AT&T has been the one breaking the consumer’s trust in the Windows Phone ecosystem. Aside from voicing our dissatisfaction we may need to start voting with our feet until they realize that they being a poor citizen has consequences.