If you're a project manager, chances are you are working with Microsoft Project and Project Server. Most the times when we go to a customer and they have this setup in place one of the first things we ask is: how is your company organized? can you explain to me this environment?
Truth is, these questions are getting harder and harder to answer. The project assets are not anymore living only in the project manager's computer anymore; they are distributed, often in the cloud.
Don't be fooled by first impressions. Big corps systems are still using simple interfaces, so much so that most of them are targeted to web browsers and everything looks like a webpage; however behind the scenes there is a very intricate mix of technologies and connections. What we see in the surface is the result of data being filtered, processed and transformed to be displayed across multiple layers.
When things change, what do we do? Whilst at this stage we don't have a definitive answer (and we probably never will), our experience has paved the way for some basic points that can be seen across multiple disciplines and categorized as best practices. Let's have a look at them:
The Sponsor
A well established enterprise project has at least 2 sponsors, or better said, 2 sponsor roles: business sponsor and technical sponsor.
The Business Sponsor: Business executive person. This sponsor has a vested interest in the success of the project. Some people don't like when I put it this way but he is the person who we will make "look good" at the end of the project. Everything the project impacts needs to be clearly affecting this person directly as well. Forget about steering committees and find THE Person which ultimately will call the shots.
The Technical Sponsor: Senior IT executive person. This person has enough power to direct people and actions without must effort. This sponsor will interact with IT departments and their domains: DBAs, SharePoint people, Infrastructure leads etc. If the project needs another active directory, he will make the calls to get it ready as soon as possible; if you need a new database, he will send the order to the database leads to fix it. This role might not have a vested interest in the project but it has a vested interest in be seeing as an active force within the project world. Without him, things would take just too long to get done.
Keep the Project Eyes on the Prize
Are you using Project Server? SharePoint? Do you really need to use them? Are they delivering the benefits you expect? These are very hard questions; regardless of the challenged they all must be aligned to the same goal: Delivery Success.
This leads to another point: Not always, but sometimes we see companies buying software just because "people are using it". More often than not, enterprises acquire software for the wrong reasons and then something is created to give purpose to that technology because...well, because we just spent $100.000 in new licenses of the SharePoint 2010.
Again, I've seen too many companies buying SharePoint solutions to later forget the reasons why they bought it and then another problem is created, to find someone to be responsible for that "baby". Purpose is lost, nobody seems to remember what was the target anymore.
Don’t buy software, buy solutions. Once the solution is in place, act quick and make sure it is delivering results. We live in a very fast-paced world and for a lot of companies out there the goal posts are an always moving target. The window of opportunity to score a goal might not be present in 6 months from now. Make sure you score them sooner and often.
Enterprise Architecture: Measure Twice, Cut Once
A couple of years ago I saw this SharePoint deployment which was created to support a Project Server installation. In theory, both products walk hand in hand...but man, what a mess was that environment. Noticed later that people did not have proper training, they lacked knowledge about SharePoint, about Project Server, they were effectivally System Analysts or Programmers who were given the task of "taking care" of the SharePoint/Project Server environment.
These products are world-class products, champions on their own; yet enterprises fail to recognize the importance of "peopleware" to work with them. As soon as possible, try to get into the guts of the current enterprise architecture, find out about their governance plans (if any) and make sure the people are living up to the expectations of the systems.
Don't Take the Storage For Granted. Replicate.
Backup. Backup. Then, Backup. And keep all 3 datasources apart from each other. In separate buildings, if possible. When dealing with Project Server or SharePoint, backup is not a trivial task. It is done in a very specific way. Invest in professional tools specifically designed to handle these environments. These tools are often expensive, but it is money well-invested.
From time to time, perform disaster recovery exercises. Because, what's the point of taking backups if they cannot be restored successfully. Keep track of the performance during these exercises; they will give you important metrics about business continuity plan and quality assurance.
Development. Test. Stage. Pre-Production. Production.
In life, there is no try, only do...fortunatelly for our systems we can create a safe environment where we can try things isolated. Make sure the enterprise has at least 4 deployment layers: Development, Test, Stage and Production. Give all access to development and as they move up the chain, revoke the access until only a few people can touch the production environment.
All SharePoint and Project Server deployments must be done in packages, with install and retract options in case of failure. All packages must have versioning and all packages must be self-contained to avoid crashing their other colleague packages.
If your enterprise does not provide this, make sure they do. We live in a world of virtualization, it is not a big deal to have these environments setup.
There Are No Small, or Big Changes. Only Changes.
Too many times people underestimate the ability of small things breaking big things. It is important to have devices in place to manage Project deployments and updates across the whole stack. Be very critical of service packs and feature updates. If not critical, try to delay their deployment. stable environment is important, a broken environment worths nothing; worst, it might bleed money. for big changes, engage with a partner with good track record of desktop transformation deliveries.
In Short…
way too often people complain about technologies, browsers, products when in fact the root of all evil is bad management practices, be it from trying to save money, be it from trying to deliver within impossible deadlines. So next time facing these project issues, take a step back and try to reflect across the big picture. The answer might be the elephant in the room.
By Edge Pereira
No comments:
Post a Comment