More on Functional Specifications

Then there are FS documents which get into details of technical design. May be the author, with a good intention to give a heads up to the development team, points out the programs to be analyzed for impact and enhanced if required. Other times, the author is not aware of the existing system functionality and works backwards from the existing code and prepares the FS by analyzing the existing code. This is not the right way to write a FS. However, in absence of proper supporting documentation, and may be lack of time from the end users to explain the current system behavior, there is no other alternative for the FS author, other than looking into the existing source code to find out what the system does. However, if the author is not technically sound, he does not figure out completely what the functionality is, and just dumps the code into the FS for the development team to figure out what to do with it. This is not the right way to go about it! What the author of the FS does not understand is that the FS is supposed to give the behavioral aspect of the system and not how this behavior is to be achieved. How that behavior is to be achieved is a question for the design/development team to grapple with. A FS as the name suggests should give only the emergent functionality of the system. There should be mention of different interfaces in the system and how the interfaces interact with each other, but rarely ever any code to tell how it may be achieved.

Functional Specifications and Gaps

Most of you would have spent considerable time preparing, reviewing or reading through pages of Functional Specifications (FS) for your projects. In fact, functional specifications are the start point for most of the project leads, technical developers and system testers. If the FS is not of good quality, all the downstream outputs like the Technical Specifications, Functional Test Plans, etc will follow the GIGO (Garbage In – Garbage Out) rule.

In my experience in enhancement type projects, the FS, normally details all that is required from the system. It flows down from the business requirements. This would have been okay if the project is a green field new development project, where everything is to be built from the scratch. But in typical enhancement projects, where there are modifications to be made to an existing code base to satisfy the new requirement, if the FS is a compilation of all that the system should do, it becomes no more than a user manual. And subsequently, when the development teams and the testing teams review the FS to figure out what changes are required to be done or what is to be the focus area of testing, they again have to fall back on the author of the FS or some other person with knowledge of the existing system, to point out the specific area of change. This clarification takes a lot of time and effort which could have been saved if the author of the FS clearly specified the area of changes.

Ideally, the FS should contain a section on the gaps between the existing functionality and the required functionality. For larger implementations, the Gap document should be a standard output for each functionality that is required.

Between the Gaps (Interfaces)

Generally an interface means a junction where there is touch point between different systems. Typically, there is some exchange of data at interfaces. Most of us are aware that in any project, managing the interfaces between various systems is of critical importance. The same is also true whenever there is any transition between anything in a project. Be it a transition whenever the project leader changes or the test manager changes or even in transition between one phase of the project to another. Whenever there is an interface, there are chances of data / information slipping in the handshake and it may pop its ugly head up later in the lifecycle of the project. What does a project manager do to manage these interfaces seamlessly?

Whenever there is an interface, the first thing to do is to define its boundaries. This is pretty straight forward while dealing with IT systems; but may not be so while dealing with processes or people. Difficult thought it may be, that is the prudent thing to do. In terms of project phases, we need to clearly define what is the entry and the exit criteria. These are the ones documented in the project plan. Similarly, for people interfaces, it would mean what are the communication channels, what are the escalation procedures and what are the bare minimum handover activities in case of team member transitioning from the project. When the project starts, there is lot of pressure on the work to be performed and apart from defining the system interface boundaries and in some cases, the phase entry and exit criteria, the human interface part is the most neglected one.

Once the boundaries are defined, the same needs to be validated. We need to refer to this as per the need of the project when the project progresses. Many times, we document everything, but do not make use of the same, again with the pretext of lack of time for these activities. Following this simple step will help us prevent valuable time and effort by keeping the important things from slipping in between the cracks.

3 months x 6 resources or 6 months x 3 resources

The other day I was toying with a hypothetical idea. Suppose a project is estimated at 18 person-months effort. Now, there are 2 options for you. The delivery can be done in 3 months time frame with 6 resources or it can be done in a 6 month time frame with 3 resources. Agreed that most of the time, in the real world that we operate in, the option 2 is not there. But for the sake of our discussion, let us assume that we have the 2 options. Now if you were to execute this project, which of the 2 options would you prefer. One of my team members says that the 6 person, 3 months would be a better choice. The logic being, since the time frame is short, number of changes introduced by business will also be less and hence less complicacy. This may not be true always. Most teams already have a system in place to handle the requirement changes in the project. There was another justification to his choice also. A team of 6 members will command more attention than a 3 member team. And may be people like to handle larger teams.

But, actually we should take the decision by looking at various fact in hand. Say, we introduce one factor here saying that 80% of the team will consist of freshers or with people less that 1 year experience. Would you still be taking the option 1 i.e 3 months, 6 resources or would you move to option 2? My friend’s decision changed with this new fact. Of course, with freshers, there will be time required to train them and make them productive. So a longer timeframe helps. Similarly, assume that you get experienced resources to staff the project, but the project is something which the organization has never attempted in the past. So, do you still go with 3 month x 6 resources or 6 month x 3 resources? Here again the learning factor is critical.

Similarly, the decision can change depending on various circumstances and various facts that are introduced. But my 2 cents is that I will opt to execute the project in the longer duration. This is because, the deliverables will be spaced out in time and hence the team will be more relaxed and thorough in their job. Longer duration also entails the risk of resources going on leave, resigning etc. So these are also the factors that need to be thought of.

Differentiating oneself in project management

Most project manager practice the art of project management with proper planning, good communication and superb execution. But if all project managers do it well, how does a project manager differentiate himself from other project managers? This is where innovativeness comes into play. A project manager has to be innovative in his thinking, planning and executing. He has to constantly push limits of innovativeness to see if things can be done in a better, faster and cheaper way. A project manager should encourage his team to find out ways to increase their productivity. He should tailor processes in such a way that project team members are not bogged down with too much of unnecessary documentation.  The project manager has to find ways to reduce non-value adding activities from the process flow and maximize time spent on value addition.

Execution

Driving the execution: All planning and scheduling, creating MPPs, filling project initiation forms, risk management sheets, budget sheets, and different processes are just meant for EXECUTING the project. Execution is the Key. Project execution is where the rubber hits the road for a project manager. The project manager is the one who drives the project execution, scanning the environment for roadblocks and removing the obstacles so that the project team can have a smooth run. This is where, the project manager has to employ all his skills in negotiating, cajoling, inspiring, driving and if required turning the heat on to get the ball rolling smoothly. This is where he needs to make quick course corrections and certain trade-off decisions depending on the various available information at hand. He needs to ensure that all loose strings are tied up at the end and project is executed successfully.

Communications during Project Management

Proactive communication: The project manager is the focal point and the conduit for all project related communications. Everyone in the project team, the business users and other stakeholders look up to him for directions. Hence, he should always be proactive in communicating to the team. He has access to most resources and holds all the strings. He can tell others what to do and what not to do and what to expect and what not to. He is the one who is expected to share the good news as well as the bad news and intimate the team on the risks and road blocks. He is the one who will rally the cause of the team with the sponsors and the business users. Hence, proactive communication is one of the efficient tools in his toolkit.

Planning in project management

I like to use a much clichéd quote while talking about Planning. “If you fail to plan, you plan to fail”. A project manager must have a planned approach to the project. It doesn’t matter if a Microsoft Project is used or an excel sheet or any other tool. But planning is the key. A project manager must be able to check the pulse of the project at any point of time. But if he doesn’t know where the project should be at a certain point in time, he will be groping in the dark to figure out if the project is on track or not. If a project is not planned, then how would you know when you have to make mid course correction? If a project is not planned, how would you know how much value has been added to the project and how much is yet to be added? Moreover, planning is not a one time act. Once the initial planning is done, the project manager must keep checking the progress of the project against the planned so as to find out the deviations if any, make necessary adjustments and then proceed.

Excelling in project management

Each project is a different animal and poses its own set of challenges. So what does a project manager do to excel in project management? What are the key attributes which help a project manager across different projects?

Planning, Communicating and Executing are three important things which a project manager should do diligently to excel in his project. In subsequent blogs I will elaborate more on these.

Challenges for a project manager

The other day, a bunch of techies were discussing about their career path. Most of them wanted to go deeper and deeper into their chosen technology and attain nirvana. One among them had displayed a keen interest in moving to a project management role and all others were critical of his choice. Their main contention was that there is no challenge in a project manager’s role! All agreed that each project had the same set of challenges and once one had done project management for one project, all other projects were cakewalk. They had somehow figured out that all challenges in life lie in technology. Coding all through the night and feeling elated when a critical issue was resolved or a bug busted was all they thought of challenges and each project according to them offered newer technical challenges. However, project management, according to them, was bland!

Some people still prefer to live in their own cocoon. However, all said and done, there is spice in project management! Agreed that a project manager independently can not complete a release. He is the person who is always dependent upon his team members. But, a project manager is the person who is responsible for getting the work done. And whenever the job gets done, the project manager smiles to himself and is contented. The project manager is the facilitator among all the different project stakeholders. And each project has a different set of stakeholders. This calls for different types of people management in different project team. Similarly, the structure of the engagement, the deliverables, and the processes, the risks, each are different in different projects. There is a lot to learn from all of these. One the most important job of the project manager is to ensure productivity increase and this requires various innovative ideas to structure and execute projects. I have felt that, apart from managing the people and keeping them focused and motivated, this is one of the biggest challenges a project manager can have which changes from project to project.