More in depth analysis about which factors you should considered before starting a project

In my previous post, I mentioned which factor are commons between heavyweight and lightweight methodologies. Now , I would like to analyze each factor more in depth:

  1. Size of the project team
    The amount of members available not only determines how many hours you can allocate for a project. In fact, it determines the team organizations for different features. For example: the smalls team allow to have less documentation and better communication between members, On the other hang, with a big team is possible try different approaches for a difficult problem.
  2. Rate of expected change
    Here there area two main aspects to be considered:  cost of change and if the the requirements are stable over time. If the cost of change is high , it’s preferable to use an agile methodology, but if the cost is low-medium and requirements are stable enough, a methodology like RUP is more appropriate because it allows you to define risk plans in a small time, given its incremental approach.
  3. Primary project goal
    For me the most important point in this case is timing in order to answer which is the deadline? The response is given by the client, usually they don’t know what they need , but they know when they need the solution for mainly external factors (suppliers and customers demands, for example). Hence, it’s necessary to establish a right timing and flexibility that the developing team can provide. Again, when the timing is short, it’s preferable to use an agile methodologies.
  4. Requirement Management
    In order to identify this element for a project it’s necessary to answer the question : “Does the project require baseline complete traceable requirements?” When a project requires a high level of definition and documentation , it’s better to use a heavy approach, while when flexibility is more important it’s necessary an agile approach.
  5. Project Communication
    An complementary point to be considered when analyzing the requirement management (4) is : How to reach an effective communication with our clients and team? For example, The Agile Manifesto mentions “The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation, but this element is also an element to keep with our client, in order to reach it reasonably considered the following communication barriers: physical, perceptual, emotional, cultural, language, gender and interpersonal barriers.
  6. Customer Relationship
    One may think that the contract is integral to defining the relationship with the customer. However, I would to discuss the following questions: What happens after the project? I delivered the project and that’s just it? I don’t think so, one of the most critical points for any business is the sustainability. When any manager is working over a project, he or she must look how to satisfy the customers’ needs in order to create a long-term relationship. You can reach this goal for example by asking the client for the next steps after the project is done, or propose a maintenance plan for the project.
  7. Organizational Culture

    The organizational culture defined by Schein is : “A pattern of shared basic assumptions that the group learned as it solved its problems that has worked well enough to be considered valid and is passed on to new members as the correct way to perceive, think, and feel in relation to those problems.” Given the previous definition it’s necessary to reach a concrete mode to establish the organizational culture, to this aim it could be useful to know what are the common elements used in agile methodologies. For example according to the study : ”The Impact of Organizational Culture on Agile Method Use” the factors that allow to implement “better” agile methodologies are:
    1. The organization values feedback and learning. Social interaction in the organization is trustful, collaborative, and competent. The project manager acts as a facilitator. The management style is that of leadership and collaboration.
    2. The organization values teamwork is flexible and participative and encourages social interaction.
    3. The organization enables empowerment of people.
    4. The organization is results oriented.
    5. The leadership in the organization is entrepreneurial, innovative, and risk taking.
    6. The organization is based on loyalty and mutual trust and commitment.

If you have any comments, just write to erwin@mikamai.com. I hope that you can reach more general vision with this overview.

What is necessary to consider before starting a project?

Since I started to work as project manager always I have been wondering how to choose the right methodology considering different aspects like number of members in a team, timing , budget, etc. However, I never found a clear and right answer in each project in which I was involved. 

First of all, it is necessary define two main concepts in software development: heavyweight and lightweight methodologies. Heavyweight methodologies are considered to be the traditional way of developing software. These methodologies are based on a sequential series of steps, such as requirements definition, solution building, testing and deployment. Heavyweight methodologies require defining and documenting a stable set of requirements at the beginning of a project. On the other hand, lightweight methodologies (also knows as “agile methodologies”) are a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.

Given the previous definitions , it’s possible find some common elements between these two approaches to manage and develop software: organizational culture, size of the project team, rate of expected change, primary project goal, requirement management , project communication and customer relationship.

This is only a general overview, in my next post I will discuss more in depth about each point and particularly when you should choose heavyweight or agile methodologies. Furthermore, I will discuss the main methods for both from the perspective of a junior project manager.

How to estimate a software project?

Estimating software projects is never straightforward and everybody has an opinion on what is the right way to do it. In this article I’ll give you my two cents on the matter.

It is usually told that the initial phase for every project should be to create a Backlog where you describe the entire project. However, I think this approach is wrong for agile projects because it compromises the flexibility and responsivity of this kind of projects. So is there any special tip for estimating agile projects? I like to use Rational Unified Process (RUP). Using this approach you identify 4 phases where you can then use Scrum Methodology or another agile technique in order to develop your project. 

Here are the 4 phases:

  1. Inception: In this phase your client and you have to be as creative as you can in order to devise all the various features of the app and identify any possible problem that can affect the end users of your future software.
  2. Elaboration: In this phase each member involved has to be more critical and concrete in order to create a detailed backlog based on User Case or User Story, depending on what is your necessity. Also here, you have to divide, estimate the effort of each activity and also prioritize them.
  3. Construction: This phase is where the coding starts and all of the team becomes involved. In this phase it is crucial to split the app’s behaviour into as many separate functionalities as possible, and ideally have one functionality ready to be deployed at the end of each sprint. Also, you should make sure that each member of your team is efficiently allocated to some task and that they know what is their responsibility and their goal within the project.
  4. Transition: as the coding part is finished, this phase is where you deliver the software to your client. In this phase it is important to make sure that the acceptance tests run smoothly and that your client get a positive perception of your final product.

Are there any disadvantages to RUP? 

One problem that may arise in application is that it is not always clear how to map the different development elements to the various phases. For instance, if you are going to create a mock-up for your app, where does it belong to? The answer is not pre-determined: if the mockup is needed to convey a general idea it will go in the Inception phase; on the other hand, if it is used for specifying a behavior of the app, it belongs in the Elaboration phase.

In my next post, I am going to talk about which tools can be used for RUP. 

Thanks for reading :D.