Posts

Showing posts with the label working environment

The problem with small companies

Image
Up until the start of this year, I have been working for small consultancy companies.  While I have always enjoyed the flexibility of this environment, I have never really had strong exposure to large organisations until now. The company I work for has been acquired by a much larger organisation, meaning that I am now part of a big company.  It’s been three months since the acquisition, and while the transition is still taking place, I am already noticing a shift in my thinking.  I would like to share this with you, and maybe add on to this post as more differences are identified. Before I continue, I just need to add that the points below are not necessary points from the company I work in.  I have been in this industry for a long time, and have built relationships with all kinds of people in different positions and companies (including my competitors) and have managed to pick up some consistencies and facts worth mentioning.  Some of these points are...

The move from Technical Expert to Manager

Image
Let me start of by explaining how things were before I became a Manager. I worked my way to a Senior ASP.NET developer with a decent amount of SharePoint exposure; it only took me 7 years. And in those 7 years I was usually poorly managed; • scope was poorly defined and not managed • no clear plan was in place or plan omitted crucial steps • timeframes were unrealistic • no quality checks were in place (faults were discovered during client demo's) • clients expectations were not managed • communications were poor • processes were not followed • resource allocation was poor (I once requested a .NET developer and my Manager believed he solved the problem when he got me a junior network administrator who knew a little HTML) • poor risk management In many cases I had reached a point where I had very little faith (or respect) for my manager that I insist that they present me with the requirements and leave me alone so I can “do my magic”, this involv...

Retaining Staff

Image
We have already established that there is a shortage of SharePoint skills; my post on that topic has been my most popular post to date. This problem becomes the root cause of other problems, and the problem I want to focus on today is the fact that the shortage of SharePoint skills places your existing SharePoint team in high demand and if proper steps are not taken to retain this staff, consider them lost. It’s unfortunate but true, due to lack of training available, the number of new SharePoint players entering the market is low (and still needs a lot of work before they can add real value to projects), so in order for a company to deliver on a SharePoint need, they need to use existing SharePoint players, and in order to do that, they need to figure out who’s the competitors key players, and make them an offer they cannot refuse. Sometimes these “offers they cannot refuse” are ridiculously high, meaning that a counter offer is out of the question, so the big question I’m placi...

Demonstrations with VHD files

Image
My current role involves more than just department and project management. it also involves pre-sales demonstrations. Prepping for a demonstration is very time consuming and very difficuly, especially since its not my primary job function. Over time, I managed to define an approach that produces great demonstrations with minimal prep time. I am going to share this approach with you. This approach is constantly improving and I value any feedback and recommendations you may have that can help me improve this approach. 1. Do not re-invent the wheel. As a Microsoft Gold Partner, focused on SharePoint and ASP.NET solutions.  My demonstrations are focused on showing off Microsoft products. If my pre-sale demonstration leads to a sale, my Company and Microsoft wins. Microsoft is aware of this and they want my demonstrations to Rock! If fact, it’s in there best interest to build detailed demonstrations for me, and that’s exactly what they did. Go to the following si...

Minimum requirements for a good on site working environment

In the past, when a software solution needs to be developed, my team build the solution in the office, tested it in the office and only when everything is built and ready, we would go to the clients offices to install and configure the final solution. These days, it’s more common to deploy the entire team onsite (clients’ offices) right from the start of the project, and while on site they do all the development, testing and configuring directly on the clients servers. This results in easy accessibility of the team, better focus, commitment and dedication from the team which ultimately means faster more accurate delivery of the solution. But the team is moving away from an environment they are comfortable with to the clients’ environment which may not be designed for this purpose, and if a few basic requirements are not in place, delivery of the solution is compromised. So if you are looking at getting an outsourced team to work in your office to deliver a solution, make s...