Tag Archives: Project management

Software Projects for Clients vs Product Development

large_6237893181The two most common business models among software companies are based on doing projects for clients or investing in product development. While both models can be rewarding and profitable, there are important differences that might make one model more appealing than the other. Moreover, initial investment and future predictability for those models are quite different. While one provides return of investment in a short period of time, the other requires a lot of time and money with unpredictable future but potentially much higher rewards.

Projects for Clients

Your clients are contracting your company for various reasons:

  • They do not have expertise or tools to do the job themselves
  • They do not have time to complete the task
  • It is cheaper for them to contract your company than to do it themselves
    Continue reading
Advertisements

Tranformation requires management support and coaching

To survive, you’ve got to keep wheedling your way. You can’t just sit there and fight against odds when it’s not going to work. You have to turn a corner, dig a hole, go through a tunnel – and find a way to keep moving. – Twyla Tharp

medium_512406438Customer is unhappy with how the provider works. Due to some contractual and logistical reasons customer cannot change the provider so he chooses to force the provider to improve by adopting more iterative and incremental way of development together with other Agile practices.

Provider is not happy with the decision. He is risk averse and any change is considered a risk. Risk mitigation of this transformation receives bigger priority than the transformation itself. Management is so concerned with risks that it does not even try to understand what the transformation is all about. Any deviation from the Waterfall model and practices established years ago is considered unacceptable.
Continue reading

Project Prerequisites: 3 types of tools no project should start without

You got that great idea for an application that will be a huge success. High level feature set and design is done and you are ready to start bashing the code. Before you do, you might go through a checklist of tasks that should be done before the coding starts.

There are three things that I consider as prerequisites of every project (apart from knowing what the high level scope of the project is).

  • Some kind of a project management tool or a task tracker
  • Version Control System (VCS)
  • Continuous Integration (CI) framework with jobs for each phase from the build to deployment

I, for one, am often inclined to simply start bashing the code. However, that temptation should be avoided in favor of a better and more stable project development.
Continue reading

This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.

Introduction

The goal of software projects is to deliver value to stakeholders. Even though that might sound an obvious statement, it can be easily forgotten in traditional Waterfall projects. The very nature of the Waterfall process fosters the creation of different departments whose job is to receive work from the previous stage, produce something, and pass it on.

A simplified Waterfall model would be:

  1. Requirements specification resulting in requirements document
  2. Design resulting in software architecture document
  3. Development resulting in actual software
  4. Integration
  5. Testing
  6. Installation
  7. Maintenance

Each of these phases tends to have separate teams and departments. BAs work with requirements, architects write design documents, developers code, integration engineers integrate, testers test, and someone installs the software. Each of these departments is waiting for others to produce something, to start working on their artifacts and, once finished, to pass it on to someone else. The value for the stakeholders is, in many cases, unknown or forgotten. Most people involved in such projects are concerned about “doing their part” and throw it “over the wall” to those coming next. Moreover, artifacts produced by one team are often not used or understood by another.

Continue reading