My View of our new Workplace

Woods Bagot is designing the new workplace for ADTA’s new building and they did a session with us about how the new workplace should look like. Following is my view of what should be in the new workplace.

 

Unlimited Motivation required for the Start-Up

A good one from Joel Spolsky, Unlimited Motivation required for keeping the start-ups going untill they reach success.

I feel even the bigger question is how to keep-up this Unlimited Motivation or in his terms how to do “careful morale management” especially when you fall in the second category of “large band of people who have some, but not unlimited, ability to motivate themselves”.

 

How Hard Could It Be?: Start-up Static

A new business is like a shortwave radio. You have to fiddle patiently with all the dials until you get the reception you want

The Five Laws of Project Management

Inspired by the Isaac Asimov’s Three Laws of Robotics, and the Laws of Identity which I posted in the previous entry. I came up with my own Five Laws of Project Management based on my own personal experience in managing projects. (BTW I personally need to improve in these as well.)

Transparency, Boldness & Effective Communication: To me these are the most important personality traits required by a Project Manager. Transparency helps in managing the expectations of all stakeholders including the business, the management and the project team and boldness enables the project manager to remain transparent even in the time of crisis.

Many Project Managers who are not transparent, bold or cannot effectively communicate fail to raise the issues at the right time or bring a true picture in-front of management. The Project Manager should have a strong character and should raise the issues at the right moment. For example, issues like time limitation, lack of resources or unclear scope of work should be raised immediately and with strength. It is much better not to undertake a project or simply say “No” then to fail it, especially when you know in advance you are going to fail and you simply kept quite on that. Similarly, issues with the team like quality of work or delays in deliverables should be immediately highlighted and communicated to the team members. 

Keeping this balance between the business, management and the team through effective communication while still managing the actual work is one of the most difficult challenges.

Documented Scope of Work: Most developers don’t like to write documents, instead they like to code and they start coding during or even before the requirements analysis is complete. Never write even a single line of code without a documented and clear scope of work which has been signed-off by the business or management. The lack of a signed scope of work is bound to put you in a loop. The loop of continuous changes and requests which will go back-and-forth between the client and your team for months if not years.

Also, always keep the scope document updated even with the slightest change in detail during the course of the project and get these updated documents signed. Having an updated and signed scope of work by the end of the project will save you a lot of trouble which generally people go through for project closure.

Team Work: I believe that “Only great teams produce great software”, so be very careful while selecting the team. The limitation of team members in numbers or in competence is one of the biggest reasons for failed projects. Make sure your team members are competent to do their job and are team players.

In case you are stuck with a team which is limited by number or have some members which do not have the required skills and you do not have the control to change or increase the team, then always factor in extra time in the project plan to cover for them.

Never create a project plan without knowing the team members and their skills. Many times I have seen project plans being made only with dummy R1, R2, R3 etc without even knowing or even without hiring the actual team members. Always remember that all team members do not have the same level of expertise and hence tasks cannot be assigned equally to R1, R2, R3.

Time Management: Efficient time management is also a big factor in overall success of the project. Nearly all Project Managers plan a little more time than actually required to complete a tasks, this time is called buffer. The buffer plays an important role for risk management and managing unforeseen issues and problems during the project.

However, in most cases the buffer time is used as a luxury and is wasted in the initial days of the project, either through a slow pace of work or simply relaxing because the project managers feels he has a lot of time on hand. This strains the project and the team at the end and if in case any unforeseen problem really comes along for which the buffer was originally intended, the project is delayed and gets into trouble.

So, never put-off the scheduled work for tomorrow even if you have a lot of extra buffer. Try to complete as much work as you can at the start of the project. Having some time at the end helps in better testing of the product and also helps in improving the product by adding additional (icing) features. It also saves the team from unnecessary strain.

Successful Closure: “Celebrate only after fully completing the Job”. Some project managers celebrate the achievement of certain crucial milestones in the project with great enthusiasm and consider the “Job Accomplished” without actually realizing that certain less important modules/tasks in the project are still not complete. This not only gives a wrong perception to the team but also these smaller less important things which are not considered “success factor” , in the end cause the failure or at least undermine the success.

For example, testing and documentation are a few phases which almost always take a hit because the project manager and team celebrate the “end of development” which such enthusiasm that they consider the Job completed and give less importance to the remaining phases. This results in multiple patches, service packs and fixes to the original product undermining the hard work and the success.

The successful closure of the project generally requires as much as hard work as in the start of the project. Becoming less focused at the end of the project always ends in issues which become apparent at a later stage. The Project Manager should remain focused till the Project is fully completed with all phases and in every detail so a true success can be celebrated.

---

Update 1: Take a look at some of humorous Project Management Laws which I found here.

Bill Gates Last Day @ Microsoft – CES 2008

Funny video from Bill Gates CES 2008 keynote about how his last would be like at Microsoft When he leaves in July 08.

TIME 100 Most Important people of 20th Century

The List is topped by Albert Einstein and includes people like 

Mahatma Gandhi, Adolf Hitler, Nelson Mandela, Alan Turing, Tim Berner’s Lee, Edwin Hubble, Alexander Fleming, Wright Brothers, Winston Churchill, Bill Gates, Henry Ford, Walt Disney, The Beatles, Oprah Winfrey, Muhammad Ali, Mother Tereasa. 

http://www.time.com/time/time100/index_2000_time100.html

No Silver Bullet: Essence and Accidents of Software Engineering

Just happened to read another gem No Silver Bullets from Frederick P. Brooks. I have already gone through some of the chapters from his classic “The Mythical Man Month: Essays on Software Engineering”.  (trying to complete)

The wonderful analogy of Essence and Accidents of Software Process described by writer fully maps the real issues on Software Design Process, the development of High Level languages and tools only serve to resolve the Accidents of the Software process but there is no sinlge answer for the Essence [conceptual design issues] of Software Process.

[Quoted]

“To see what rate of progress one can expect in software technology, let us examine the difficulties of that technology. Following Aristotle, I divide them into essence, the difficulties inherent in the nature of software, and accidents, those difficulties that today attend its production but are not inherent.

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.

If this is true, building software will always be hard. There is inherently no silver bullet.”

So, what is the solution for these inherent and complex software issues [Essence] which the modern day tools and languages cannot address or which cannot be guranteed the way the language/tool productivity can be guaranteed. One of the possible solution the writer has presented is “growing” good designers.

[Quoted]

My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded. Not only salary, but the perquisites of recognition–office size, furnishings, personal technical equipment, travel funds, staff support–must be fully equivalent.

How to grow great designers? Space does not permit a lengthy discussion, but some steps are obvious:

• Systematically identify top designers as early as possible. The best are often not the most experienced.
• Assign a career mentor to be responsible for the development of the prospect, and carefully keep a career file.
• Devise and maintain a careerdevelopment plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo-design and technicalleadership assignments.
• Provide opportunities for growing designers to interact with and stimulate each other.