Communicate Early and Often: Real Lessons for the entire Team!

I’m often asked, “What’s the one thing that makes the difference between a successful project and a failed project.”  In my honest opinion, the success of a project comes down to communication.

Yes, there are all sorts of other things that can make the difference between success and failure, but I think the root of most of those problems comes back to communication.  You can diligently move through the lifecycle or through your sprint, you can create all of the project documentation and artifacts that you want, you can create pretty gantt charts to show the team, you can track all of the money spend and forecast future expenditures, you can track all of the defects and their remediation plans, you can check off all your milestones, however, none of that will make a difference unless you are communicating properly up through the project hierarchy and across the project team.  And, yes, there are two very different communication paths – each seeking their information.

The first path is the tactical path – cross communication between the people responsible for the day to day activity within a project.  These are the hands on people, making the product, building the processes, and changing the way things work.

The second path is the governance path – communicating up through the management chain to the sponsor.  The sponsor is the owner of whatever is being delivered, and ultimately owns the decision of whether to keep on working the project, rework the project if the results aren’t up to spec or to abandon the project.

Both communication paths are critical and if team members don’t support the communication strategy – you’ll be doomed to failure.  Don’t get me wrong, you might ultimately get your project into production, but you’ll have spent more money and your timeline will most likely have suffered due to rework, or you’ll have delivered the wrong thing.  And you’ll know it when people avoid using what you’ve built or it quietly gets shoved into a trash can somewhere along the way.

Let’s start at the beginning …

Who’s the Sponsor for your project?  Are they clearly articulating the vision?  Are they controlling themselves and others as it relates to scope?  Are they plugged into the project?  Do they know the major risks and mitigation strategies?  Do they understand the overall budget and do they know if the team is on track to meet or beat the budget?  Do they give guidance when the team is up against an obstacle that they can’t solve on their own?  Do they clear the roadblocks in front of the team? 

Or, do you find yourself learning new wants/needs every time you say hello to the sponsor?  Are they ignoring the risks the team has identified?  Are they unattached – do they really care about what is going on in the project?

What about the Project Manager?  Is your Project Manager setting expectations up front?  Are they letting you know how often you’re going to meet as a team?  Do they do frequent stand-ups to get the quick status checks?  Do they communicate regularly and update you on the status, risks and mitigation plans?  Is the Project Manager holding people accountable to deliver what they said they would, when they said they would?  Is the Project Manager tracking against the budget and keeping the Sponsor in the loop?

Or, does anyone actually know who the Project Manager is?  Did they set clear expectations for the team at the beginning of the project?  Did they communicate who owns what pieces?  Did they explain how often you would meet and what the format of the meetings would be?  When was the last time they talked to you about the pieces you own?  Do you know how the other pieces of the project are coming along – will they be ready when you’re ready?  Is the Project Manager out removing obstacles and ensuring that you can stay focused on your job?  Is the Project Manager providing you the details you need to know whether the overall project is on track?  Are they ensuring that decisions made are being distributed across the entire team?  Is your Project Manager checked out?  Do you see the Project Manager only when something is going wrong and they want to point the finger and redirect the blame?  Is the Project Manager in reactive mode only dealing with issues when they become critical?

And let’s not forget the team members – are they keeping everyone in the loop on the most recent changes to the schedule?   Do they immediately notify team members and the Project Manager when they see a risk that might affect the project down the road?  Do they escalate an issue when a vendor is not delivering functionality within the timeframes identified?  When they identify an issue, do they also provide potential solutions to resolve the issue or catch backup on the timeline?

Or, do they ignore the entire team when they have hit something unexpected?  What about when a requirement changes, any notice from the BA?  Whoops, did that interface change?  I’m sorry – didn’t you know that I won’t have that done?  Oh, that decision on the pricing has changed, didn’t you get the update?

None of this is rocket science and it doesn’t take someone with a masters or a doctorate to figure out what the issue is.  Get up out of your chair walk down the aisle, take a right and let someone know!  Use your scrum meetings to share issues/concerns with the team.  Let them know when something has gone off track.  Instant message the Project Manager – trust me, they want to know.  Pick up the phone and let someone know that something in the market place has shifted and the sales projections need to be updated.

Part of being a team means that you’re making some commitments – these are not optional:

1. Be accountable for the work you are supposed to complete.
2. Listen to other team members in project meetings – that means you won’t be checking your email or browsing the internet.
3. Be an active participant in project meetings – interact with team members and move the ball forward.
4. Share your knowledge with other team members – lift those around you.
5. Provide a regular status – you need to agree on what regular means.
1. As a team member that may mean daily.
2. As a Project Manager that may mean weekly to the Project Office and biweekly to the Project Sponsor.
6. Immediately communicate risks or issues with mitigation plans as soon as they are known to the Project Manager.
7. Immediately notify the Project Manager and other team members when you know you’re not going to be done with your assigned piece on time.
8. Be a problem solver – when others identify issues, be willing to help find solutions.
9. Be flexible – we all know things change, be the one to find the way to address the change.
10. Be respectful in how you communicate and interact with others, be supportive when needed.

I’m not saying this is going to fix everything that is wrong with the projects you work on.  I am saying it will make things go a lot smoother.  We need to trust each other enough to be open and honest with each other.

Tags: Project Management; Software Development Lifecycle; Teams; SDLC; Change Management;

For more information on David L. Collison: LinkedIn Profile

When Actions Fail To Match Promises – The PMs Nightmare

We’ve all had those moments when we finally realize people on our projects aren’t living up to the promises that they’ve made.  Ugh …. Can’t we all just do our jobs!   Apparently, not!  The real question, what are you going to do about it?

We all make promises in our lives – to our wives, our children, our parents, our bosses, our teams.  It is part of life; it is part of our character.  Sometimes these promises are small; sometimes these promises are the difference between a company meeting its goal and failing.  Unfortunately, we don’t always live up to our promises – sometimes it is minor, sometimes it can really screw things up.  And, like it or not, it’s your job as the Project Manager to hold people accountable.

One saying that was drilled into me by one of my bosses was the phrase, ‘Under promise and over deliver!’  In short, take time to think through what is being promised and ensure that you give yourself enough time to deliver a quality solution – then when there is agreement on what and when you will deliver, beat the expectations.   Find a way to deliver early or to deliver more than what is being expected.  Or better yet, find a way to delight your customer by delivering more than they expected ahead of schedule!

Unfortunately, life happens and occasionally we end up running into a wall when unexpected bumps send us off the path we were expecting to travel.  Whoops, didn’t realize that the changes were impacting several other applications that rely on this particular chunk of code – now I have to test a whole lot more than I was ready to test!  Whoops, who knew, the vendor that was going to install the new server got delayed and won’t be here for another two weeks!  Whoops, I thought it was only going to take a week to code that new service, it’s really going to take a week!  Whoops, I just figured out – I’m not getting full requirements and now I’m going to have to spend some time documenting what really needs to be done before I can actually start the design and coding, that’ll be at least a month delay!

As a Project Manager you’re going to hear every excuse under the sun.  There will always be a reason for why it didn’t get done!

First, you should never be surprised – in fact, if you’re doing your job right, you’re probably going to know things are getting off track before other people on the team are willing to admit that there is an issue.  How?  Simple, communication!  Remember, in past posts, I’ve talked about the concept of walkabouts?  This is your most valuable tool as a PM – walking around talking with people, 1-to-1 video conferencing , instant messaging, or phone calls.  Stay in touch with what people are doing – when approached casually, they will usually tell you more than when they are sitting in a status meeting.  It’s easier to share when they’re talking alone with you!  You can use this time to verbally catch up on what is being accomplished and most importantly, to talk about what issues they are facing.  What are the things that are standing in their way?  Are they seeing any delays in the stuff that is working its way through the pipeline that is supposed to be used to help them get their assigned work completed?  If so, who or what is causing the delay?

Then, don’t over react!  Don’t punish the person that is giving you the news – otherwise they’ll stop!  Find the root cause of what is causing the delay – 9 out of 10 times, it’s not what you initially thought.

Eventually, you will figure out what is really causing the delay.  Then you need to open up a dialogue with the individual responsible.

• Does the individual just need to be reminded of the need for the work that they’ve been assigned to be completed on time so that they next person in the workflow can do their piece?
• Can you talk with the team manager and get other tasks reassigned so that the individual has more time to devote to your project?
• Is the individual not staying focused and therefore delaying work on your project – spending more time than they should on Facebook, Twitter or the general Internet?
• Is someone intentionally attempting to derail your project because they don’t agree with the direction?

At some point, you’re going to run into a situation where the person does not want to cooperate.  Then you’re going to have to use your communication skills to get through the situation.  If you’ve never read the book, “Crucial Conversations Tools for Talking When Stakes are High, Second Edition”, by Kerry Patterson, Joseph Grenny, Ron McMillan and Al Switzler – pick it up today, or download to your iPad/Kindle.  This book is an excellent reference when faced with conversations that are going to be difficult.

The biggest ‘trick’ in the bag is to use the dialogue to bring all the information out in to the open and provide a safe path for both you and the other individual to have input into the solution.  It is driving to get results with and through the people you are dealing with on a daily basis.

Your goal is to understand what is driving the behavior of the other individual, then to ensure that the individual knows that you’re looking for a win-win way to move forward.  If you approach the conversation in the right manner, allowing them to share with you the issue and to be part of the solution, you will reap rewards.  Stop, listen, let them tell you their story and allow a little empathy to show through, then you can begin tackling the issue of how to bring the assigned task back on track.

Tags: Project Management; Software Development Lifecycle; SDLC; Change Management; Crucial Conversations;

For more information on David L. Collison: LinkedIn Profile

Project Management – Words of Wisdom to the Uninitiated

So, you’ve got your first job as a Project Manager (PM) – congratulations.  Now, you’ve been assigned your first project and you’re looking at the elephant thinking to yourself, what do I do next?  Well, jump in with both feet seems like a good idea – but which end of the pool and how do I tread the water to keep my nose above the waterline?  I’ll attempt to give some advice in this posting – take it for what it’s worth, it may not work for you or your organization, but you may be able to find a nugget in here that gives you a ray of hope!  I know that it has helped me and those individuals that I’ve mentored over the years.

So, most development projects are broken down into phases along the following lines:

1. Discovery – this phase allows you to identify the stakeholders of the project and then working with the stakeholders identify the boundaries of the project, what will and won’t be included in the overall scope of the work.
2. Requirements – this phase allows the team to clearly identify the requirements associated with the project – this should include functional and non-functional requirements.  By the way, this is a personal pet peeve of mine – if requirements don’t include at least a high level explanation of how the user will test/validate that the requirement, then the requirement is not complete.
3. Technical Design – this phase of the project allows the technical side of the organization to take the requirements and translate them into an overall roadmap that identifies the application silos that will be touched and how everything ultimately fits together – this is the roadmap that technical teams will use to build the applications and underlying infrastructure.
4. Development/Construction – this phase of the project allows the teams to construct the functionality that will be delivered as a result of the project.  This should include not only the technical pieces, but the business pieces as well – marketing plans, supporting documentation, etc.
5. Testing – this phase of the project is used to confirm that we have not broken current functionality and that we have validated that the new feature/functions work as documented in the requirements and the technical design.
6. Implementation – this phase of the project allows the teams to move the application and underlying infrastructure changes into the production environment.

Clearly, looking at all of this when you’re first assigned to a project can be overwhelming.  As a PM, how do I know what tasks to put in the project plan and how long do I have those tasks last?

Really, this becomes much simpler than it looks – let’s take the first phase, Discovery.  We understand what needs to be delivered within this phase of the project – in most organizations, it will look something like the following:

• Project Request Document – gives the background justification for the project, a very high level scope of the project used to inform others what is being delivered, extremely high level expenses/costs, extremely high level sales goals, and competitive information.
• Project Concept Document – once the project request is signed off by the stakeholder, this document dives down to give more details – if the project request document was the 100,000 foot view, this takes down to the 50,000 foot view and includes things like the formal project scope/boundaries, project needs analysis, market assessment, proposed timeframes.
• Vendor Due Diligence – this activity confirms that viability of outside parties to deliver critical components of the project.
• Business Case – this takes the Project Concept and builds the other components around the base to provide management with the complete picture allowing them to make the go/no-go decision - sales commitments, revenue projections, product demand and strategic fit information.

Other organizations may drive more or less artifacts through the Discovery phase of the lifecycle.  All that being considered, there are a base set of deliverables that are expected at the end of the Discovery phase.  Additionally, it’s not just a matter of the deliverables/artifacts being generated, it is disseminating that information to the decision makers and getting direction on the go/no-go decision.

So, let’s work backwards – let’s say you’ve been given 3 weeks to perform this activity.  You know that you have to have a meeting with the decision makers at the end to review the information and get the go/no-go decision.  You know that the expectation is to deliver the necessary artifacts 3 days before the meeting.  So if you have a 3 week timetable – that’s a total of 15 business days.  Assume the meeting with the decision makers is held on the last day, that means the documentation must be delivered on the 12th business day.

As the PM, you need to have the following discussions in your phase kick off meeting:

• Who needs to be included in meetings to create each of the deliverables/artifacts – Project Request, Project Concept, Vendor Due Diligence and Business Case?
• We have 12 days to complete each of the artifacts/deliverables for the Discovery Phase – how often do we need to meet on each artifact and how long should each of those meetings last?
• What are the check points in each of these meetings to ensure that we are on track to complete the documents in the required amount of time?

Now you have a timeline to work with – 12 days – and it becomes a matter of accountability.  Setup the meetings, ensure people are attending and contributing.   Your markers for each meeting – make sure you have an agenda, then take and distribute notes:

• Validate that the work that was supposed to be done between meetings was completed.   Get proof – sorry, I tend to be skeptical.
• Review agenda items – check off those items completed, note those not completed and create action/agenda items for next meeting.
• From the review of agenda items – when looking at items that were not completed, are there new risks/issues that need to be highlighted and mitigation plans created or does someone just need to catch up on work assigned?
• Review status updates across the team – ensure people are highlighting what is needed from each other to complete activity needed in this phase of the project.

Sounds simple, right?  Now, as a PM, it’s your responsibility to not to be surprised in your meetings.  While you may be meeting with parts of the team several times a week and the whole team on a weekly basis.  It’s your job to stay on top of things between meetings.  You should never walk into one of the meetings you are holding and have it be the first time you hear that someone is behind schedule.  You need to be performing walkabouts – moving around on the floor, instant messaging, or calling people to discuss how they are doing, what’s working, what’s causing them problems and staying on top of activity.

If between meetings, you become aware of a roadblock – it’s up to you to find ways around, under or over the roadblock and allow people to continue to move the process forward.  Who can you bring into the discussion or work activity to help the person forward?   What work activity can be reassigned?

Now, rinse and repeat for each of the following phases.  The difference being that at the end of the design phase, you should be able to obtain feedback from the team identifying all of the remaining tasks/milestones and timelines for the project.  This then becomes the baseline that you measure everything against.

Tags: Project Management; Software Development Lifecycle; SDLC; Change Management;

For more information on David L. Collison: LinkedIn Profile

Microsoft and IBM - two giants falling!

I credit the fact that I'm in this industry to Microsoft and IBM.  I was enthralled with the introduction of a small business class computer that you could place on any desk and with the OS and applications that made computers accessible.  Applications like Lotus 1-2-3, VisiCalc, Wordstar and dBase III.  Yes, this was long before the introduction of graphical OS - they all ran on MS-DOS, don't cringe, a text based OS.  And, yes, that means I was playing with these systems shortly after IBM introduced the first IBM PC - the year was 1983 and the IBM PC was only 2 years old.

While attending college, I got a job installing PC's, setting them up and introducing the client to their new system.  I also picked up computers that weren't working properly and brought them back to the service desk to be repaired.  At the time, PASCAL was the language of choice.  I was learning how to program in this language in school and the company I was working for allowed me to take a Compaq Portable PC back to my dorm room.  I convinced my instructors to let me use the Compaq for my programming assignments (I think I was using a copy of Borland Pascal - but my memory is a little hazy) versus having to logon to the DEC PDP 11/70 - a mini computer.  I also was able to get my hands on copies of Microsoft Assembler and Microsoft Basic.  Much as I hate to admit it - that was geek heaven at the time.

I loved the PC and MS-DOS.  Config.sys and AutoExec.Bat were my friends - I knew how to get into these files and make changes to the way that the system operated and the utilities that would be loaded into memory.  Microsoft and IBM made it fun and easy to use these new computers and made programming accessible.  Ask my folks how many hours I spent in front of those early computers teaching myself without realizing how important this would be for the career path that later followed.

I ended up working for a couple of computer resellers early in my career - doing everything from installs, service calls, sales and teaching.  Yes, I actually ended up teaching computer classes on dBase III and Lotus 1-2-3.  Teaching dBase III actually ended up being the precursor that allowed me to get into programming.  I started playing with Clipper - a compiler for the dBase III language.  Then I applied for and got a professional programming job using Clipper.  From there, as they say, the rest is history - moving through my career as a developer, consultant and manager.

None of this would have been possible without IBM and Microsoft partnering together and creating the business class personal computer.  Ask anyone I knew back in those days and you'll hear about how I looked up to these two companies - in my mind, they were at the top of the top, no other company came close to the respect that I held for these two companies.  And my early career was built on this market - migrating to Visual Basic and Visual C++ when Windows took hold.


IBM lost their way and fell down against the IBM compatibles - eventually selling their PC business to Lenovo.  They couldn't figure out a way to compete on cost with the competition.  Go figure, literally, the pinnacle of multinational companies could not figure out how to leverage resources across the world to compete against much smaller companies.  (If you're looking for the full story on IBM's fall - and not just related to PC's - I'll send you to I, Cringely for further reading - The Decline and Fall of IBM.)  IBM is gone from the PC industry and is seeing a decline across their other product lines.  As much as I hate to see this company in the condition it is in, I tend to agree with the assessment that IBM is on it's way down.

Microsoft on the other hand successfully out maneuvered the industry - yes, Apple was there, but they were a niche player.  Along the way, Microsoft made blunders - but was always able to recover.  And why not - they really didn't have any competition, to the point where they were charged and found to be a monopoly. Using their weight to drive competitors out of the market.  Ever hear of the phrase embrace, extend and extinguish?  If you haven't - look it up, it will give you an excellent run down of the way Microsoft controlled the industry.

The first chink in the wall of Microsoft was the open source movement.  Linux in particular and the open source programming languages and tools.  More and more developers became disillusioned with the walled garden of Microsoft and began looking for alternatives - myself included.  Linux, check!  Apache, check!  MySQL, check, Python, check!  All open source, no cost barrier to development or deployment!  What started out as an irritation became a full panic at Microsoft as they ranted about open source being a cancer in the industry.  Today, Linux runs the web.

Then along came the iPhone.  Microsoft initially made jokes about the iPhone - well, that humor came back to bite them in the back end.  The iPhone and iPad have ended the PCs dominance.  I know more and more people that are foregoing the purchase of laptops and desktops at home to purchase 1 or more iPads.  And I'll also wager that Chrome is becoming a bigger and bigger headache for Microsoft.

Apple ruled the smartphone market for several years until Android came along.  The one thing you won't hear is Windows Phone.  Ok, I'll give Microsoft credit Windows Phone isn't bad, but I still prefer iOS.  I'll use Android if I must, but I can never see myself going for Windows phone.

This is where I think Microsoft has really gone nuts - they created Windows 8 to run across phones, tablets and traditional PCs (laptops and desktops).  For those of you that like Win8 - that is your choice.  All I can do is speak for myself and I can not stand this Frankenstein of an OS.  Mindlessly switching me between Metro and traditional windows mode when I want to do various tasks.  I won't go into all of the details, there are plenty of articles out there that get into the details.

Microsoft used to be there for the developer - building the tools and making it easy to get stuff done.  I can't say that anymore.  Developers have moved on to iOS and Android - if it's convenient they'll build a Windows version, but it's usually well after they've developed for the other mobile platforms.  Don't get me wrong, both iOS and the Android environments have their issues, but developers want to be there, not with Microsoft.  And the consumers have spoken as well - at the end of 2013, Windows Phone had a whopping 3% of the world-wide market share of smart phones.

Today's kids want an Android phone or the iPhone - and, yes, that includes my kids.  Do you think when they're ready to move up, that they're going to go with Win8 or with an iPad or a Mac?  Some of them will move to Android tablets.  Fewer and fewer of them are going to choose Win8 machines.

I don't know what Microsoft can do to change the equation.  Is it too late?  Well, the good news is Microsoft has a lot of money in the bank, they've realized that Balmer was leading them off a cliff and have replaced him, and they still have a following.  Will something change in the equation - who knows, but if I was a betting man, I'd say Microsoft will never have the power or control that they had in the 90's and early 2000's.

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile

Implementations - When Things Go Bump In The Night!

Sometimes bad things happen.  The question - how fast are you able to respond and put things back on track?

Technical teams need to plan and test their ability to rollback changes that are negatively impacting users.  This needs to be a formal part of your process - sometimes that means falling forward, fixing the broken functionality in production; sometimes that means falling back and reverting to a known state where the application was functioning properly.

Let's be honest - none of us are perfect all of the time.  Occasionally, we are going to miss something and move code into the production environment that ends up breaking things and making life miserable for the folks actually using the application.  

What have you done to prepare for this moment?

1. Does your implementation plan include steps to proactively monitor the system as changes are moved into production?
2. Does your implementation plan allow time for you to look at patterns of application activity to validate that you are not seeing patterns that would indicate that something is broken within the application?
3. Does your implementation plan include validation steps to ensure that the application is acting accordingly and that the new/changed functionality is working?
4. Does your implementation plan identify risk points and fallback strategies?
5. Have you tested your implementation plan?
6. Have you tested your fallback plan?

Every environment is different - but we mostly face the same types of challenges.  Breaking things that users expect to work is not what we want to do, but occasionally, it happens!

Yes, planning your implementations takes time.  Yes, planning validation steps and inserting them into the overall implementation plan takes additional time.  Yes, testing your implementation plan chews up more time.   And, yes, testing your fallback plan takes even more time.  That all being true, failing to do any of this means that your operating by the seat of your pants and your recovery time when things go bad will hurt you worse.

1. When your application fails - the reputation with your customers takes a hit.
2. The longer the outage increases the risk that your customers will walk away from you and begin to use a competing application?
3. Will an outage impact your revenue stream?

Now, all that said, sometimes even with all of the best planning, you're going to get caught.  It's bad enough when it's a web based application/service where you can make immediate changes or perform and immediate rollback.  However, what if it's software that you're sending out to customers - that they install on their systems?  How do you think Microsoft feels when they send out one of their regular patches only to find out that it causes the blue screen of death.  This can affect millions of computers around the globe.

Not to hit Microsoft too hard - but, in April they released a patch to Windows 8.1 that was required before any other updates could be applied.  This impacted retail customers as well as corporate customers and was not fixed until early May.  I'm sure that they ran their standard quality processes against the code prior to the initial release in April - but something obviously got by the testers, and it wasn't a minor issue.  It took time for Microsoft to hit the reset button, but in the meantime their customers were in an uproar.  

I'm going to walk softly here because as a developer it could happen to me or the teams that I lead.  I'm not trying to single out Microsoft - anyone that writes software has had to recover from a misstep when loading code into production or sending out a new release.  What I'm advocating for is that you implement solid processes that minimize the risk to your customers, your team and your organization.

What are you doing to mitigate the risk of an implementation/software release going bad?

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile

Back In The Saddle Again ...

I have been distracted with several items over the last few months and apologize for my absence.  That said, let's dig into our discussion and see if we can do some sharing.

Sharing my thoughts on Microsoft ...

My early career was built on Microsoft.  I graduated high school in the early 80's just as the IBM PC started to be sold.  Yep, aging myself.  Anyhow, after learning BASIC and Fortran on a DEC 1170 - I migrated to programming on an IBM PC using BASIC and then learning PASCAL and Assembler.  Then I learned dBase III and Clipper - learning to program against databases.  All on a PC with floppy drives - yep, no hard drives at that time, just dual floppies where you needed to swap disks to manage all of the data.  None of this would have been possible without the OS that Microsoft built and licensed to IBM.

Then in marched the IBM compatibles - Compaq the most successful in the early days.

Not only was I programming, but I also ended up selling IBM and IBM compatible equipment.  The company I worked for let me lug around a Compaq portable while I worked for them.  I had access to Microsoft compilers for Basic and Assembler, and used Borlands Pascal.  The company I worked for also had me teaching programming courses.

Along the way we transitioned to Windows and I learned how to program using MS Visual Basic.  This became my bread and butter for quite some time - allowing 2 buddies and I to eventually open our own consulting firm.  We built a healthy practice, hiring additional developers and working for several local and national companies.

I was able to enter the field of software development right as Microsoft was transitioning the industry.  Moving us all from monolithic computers operating in the back room to a vision of a computer on everyone's desk.  I knew the first time that I saw the IBM PC - that it was my future.  I didn't look back - I wanted nothing to do with the mainframe class machines, I wanted to figure out how these small (by the standards at that time) boxes could be used in business.  And oh how the world turns as I know manage development activity on mainframe class machines and Unix/Linux clusters.

For a long time - Microsoft owned the development community.  They created tools that allowed us to transform the industry, thereby further fueling their growth.

Then Microsoft lost it's way - it became more focused on protecting it's cash cow and locking developers into their environment.  Companies attempted to displace Microsoft and turn us onto their platform, but most failed.  Then along came the browser and smartphones - to say Microsoft was not ready would be an understatement.  They nearly lost the browser wars and only woke up at the last minute to use their monopoly power of the OS to win the browser war.  The smartphone is a different story.  Windows Phone is an also ran and I'm not sure Microsoft will ever have the chance to be a driving platform within the phone space.  Oh, they'll stay in, but in my opinion, they won't truly compete with Google or Apple.  They missed the boat.

On the desktop Win8 was a colossal fail - yes, they can brag about the numbers sold, but most companies are using the license terms to downgrade to Win7.  I personally hate Win8 - it's a mindless combination of OS modes that make no sense on the desktop.  Win8 may be pretty on a tablet and phone, but on the desktop it only irritates.  Where I used to regularly recommend Windows equipped laptops and desktops to friends and family, I've now moved to pushing Apple's ecosystem.  Many people only need an iPad, and for those that need more, the MacBook Air,  MacBook Pro, iMacs and Mac mini's are the choice.

And this is a stunning development - ask my family and friends, for a long, long time I viewed Apple skeptically and always thought they were too expensive.  Well, you may pay more for a Mac, but if that allows me to walk away from the problems that I experience in the Windows environment and mess that they call Win8, it's worth the money.

Where the Apple ecosystem just works, the Microsoft ecosystem confuses - mindlessly flipping between metro mode and desktop mode, sometimes for no apparent reason.

Of all the expert articles written about this farce of an OS and what Microsoft needs to do to fix it, I vote for Windows Red as documented by InfoWorld.

Can they come back, who knows?  They'll never go away, they're too big and have too much money in the bank.  They would really need to screw up to disappear, not saying it can't happen, but the chances are remote.  They have become the new IBM - too big to fail.  

All that taken into context, the best move they could have made was to ditch Balmer and replace him with Satya Nadella.  I don't think Balmer would ever allow Office on the iPad, and while the package introduced by Nadella is handicapped, it's at least a start.  Microsoft appears to be making some steps to stop the ship from sinking - I wish them well, but really wish they'd kill the FrankenOS on the desktop.

I know this has nothing to do with Project Management or specifically with software development, but I thought I needed to do a mind dump on this topic.

Tags: IBM; Microsoft; Windows 7; Windows 8; Win7; Win8; Change;

If you'd like more information on my background: LinkedIn Profile

Languages, Languages, Languages ...

I speak regularly with High School and College level students promoting careers in technology - specifically careers with Applications Development, Quality Assurance and Project Management.  I enjoy interacting with the students and telling them what they may experience as they transition from the role of a student into the professional workforce.  Along the way, I also ask students to think about interning - either with my organization or some other organization in the area.  This is a fantastic opportunity for students to get real-world experience, become visible to an employer, and begin to understand some of the concepts taught in the classroom as they apply them to tasks in the workplace.

Many times, students ask me why we use the languages that we use and why we don't take advantage of the latest scripting or language fad.

My answer - why should I?  They seem to be stumped by my response.

Well, really, why should I?  Why should my team be disrupted on a regular basis just to use the latest language fad?  Why should I continually experience a productivity loss as team members shift between languages?  Why should I take the risk of bugs being introduced into production systems because the developers are not experienced with the language/tools that they are using?  Why should I risk customers being subjected to performance issues because the developers haven't figured out how to optimize the programs they're creating?  Why should I make the on-boarding experience for new developers more difficult?

Look, there are a handful of languages that we've committed to within our organization.  Four languages are used to generate all of our production level systems.  A couple of additional scripting languages have been used to create internal tools that assist us in production setup, as well as assisting us in ripping through logs to find specific information when we are researching issues in our environment.

Programming languages are programming languages - if you're a good programmer, you can pickup any language.  If you're a good developer, you understand that once you understand the various constructs of a language - learning a new language simply means translating the specific syntax of the language you want to learn to the languages you already understand.  It's translating how to use an if statement, a loop, a case statement, etc.  

Let's say it take you a month to become familiar with the new language - assume that your productivity drops by 50% and for 6 months after your initial learning period, you're running at only 75% productivity.  That means that over a 7 month period - you're productivity has cost the organization 8 weeks of development time.  Now multiply that across the entire team.  Assume their are 10 members on the team - that's a total of 80 weeks of lost development effort.  Assuming this same 10 member team and an average of 2 weeks vacation time for each team member - you have a total of 500 weeks that you can allocate to development efforts.  The end result is that you've stripped the team of 16% of the overall capacity of the team for the year.

Now, the numbers discussed above don't even take into account the impacts down the line as we move through test, implementation and post-implementation support.  How much more time will the Development Team need to create and execute unit tests?  How much time will the Development Team need to perform integration and regression testing?  How much time will the Development Team need to perform load testing?  How much extra time will the Quality Assurance Team need to test the application?  What additional issues will be experienced during the implementation of the code into production?  Can you quantify the number of additional issues that will be identified post-implementation that will need to be fixed and how much additional time it will take to address those issues?
 
The impact on productivity across the organization is significant and material - that is real time that prevents projects from being initiated or completed.  That's time that allows your competitors to either close the gap or get further ahead.

I don't mind taking on a new language when there is a need, or when there is a specific purpose.  Over the last couple of years, we've actually brought in specific tools that have allowed us to move in to the mobile market.  At this point, a select number of developers within the overall team have been exposed to these new tools.  Over time additional developers will be brought in to the loop.  Here, there is a specific need - our tools at the time did not lend themselves to creating cutting edge mobile apps.

Take a step back and look at the decisions being made within your organization.  There's usually a reason that organizations aren't moving as quickly from one language to another as developers would like.  To the developers that would like to get an organization to change - don't just go in and say that you need to be able to use a new language.  Document what you feel the benefits are, and just as importantly recognize the impact to the organization and craft your discussion points to address the costs that the organization will incur.


Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making;

For more information on David L. Collison: LinkedIn Profile