Jonathan Menasches

During the last few months at PSF we have been developing a website for a big financial entity in the U.S.
One of the challenges of the project was to obtain the information from different exchanges were our customer makes transactions.
We needed to capture all the information from those transactions because it was necessary to replicate them into our system.

The way these exchanges sent the information was via FIX and FIXML protocol. This meant that for us to get the information required we had to request it through these protocols and handle the responses from the exchanges in the same way.The good news was that for FIX protocol there was already implemented an open source project that we could adapt and use: QuickFix. It was marvelous, once you understand how it works; it becomes your best friend.

But as we all know, not everything is looked through rose-colored glasses at software.For FIXML protocol we did not have any open source application that was able to help us, so we had to implement it from scratch. Moreover the exchange (because it was only one) was also implementing an HTTPS connection, making the approach completely different than the one we used when implementing with QuickFix for the FIX protocol.

Hopefully, we have great developers that could handle this kind of issues. One of them is Julian Mendiola who was in charge of the implementation of two applications to establish the connections with all the exchanges we had to manage. Both applications were a success, not only for its performance but also for the fast response of our developers, building the applications in a really short time.

I recommend visiting Julian’s blog. He has written some posts about FIX and FIXML protocol and some samples of what we have been building.

Introduction

As I mentioned in a previous post I had the pleasure to assist to the first Project Management congress organized in Argentina.

In the congress I listened to a speech given by Miguel Bilello who talked about bad or lack of communication during a project. In this post I will try to expose what I learnt of that speech and what are my conclusions around this subject.

The statistics

The CHAOS Report has been published yearly since 1994 by the Standish group and its purpose is to research the reasons for IT project failure in the United States.

The definition of a projects success and failure is defined differently by different people. The Standish defines them as follows:

Success: The project is completed on time and on budget, with all features and functions originally specified.

Challenged: The project is completed and operational, but over budget, late, and with fewer features and functions than initially specified.

Failure: The project is canceled before completion, or never implemented.

We can see in these graphics that we have improved 18% on project success but we are still failing or being challenged a 65% of all the projects. This is a big number. So we should analyze this issue to try to understand why projects are still failing.

You can see more about these reports on http://www.protose.org/_archives/2004/10/software_projec.php

Why do projects fail?

This is a difficult question to be answered, isn’t it?
Well, let’s start with the beginning, identifying factors and causes of projects failures:

1. 1. Not clear objectives.
   2. Constant change of requirements.
   3. Poor project planning.
   4. PM Naivety: Such as thinking that developers work 100% of the hours they come to the office. They do other stuff such as meetings, read e-mail, etc.
   5. Setting unreal expectations
   6. Lack of communication during a project.

Now that we have identified some on the most common issues that affect projects we can try to analyze them.

Factor 5: “Setting unreal expectations” was analyzed in some of my previous posts

In this post I will expose my ideas of the “Lack of communication” using the lessons learnt of the speech given by Miguel and my own experience on projects

Communication components

To analyze the lack of communication we will start by understanding what a communication is and which the are different elements that compose it.

Communication can be defined as a process that allows organisms to exchange information by several methods.

We can say that the basic components of a communication are:

• Sender: Is the person that sends a message, and is in charge of making it reach the destination.
• Receiver: Is the person that receives a message, and is in charge of decodifying it.
• Channel: Is the medium defined for the transmition of the message.
• Noise: Are the external stuff that affect the message. We use this concept to envelope everything else that is not the sender, the receiver or the channel.

Communication failure: System issues

In an ideal world if every component of the communication worked properly and accomplished correctly its function there would be little or none communication issues. The problem appears when we apply these concepts in a real world.

To understand these problems we can figure out the following example:

Let’s suppose that a PM needs to assign an urgent task to a Developer that works in another office. So the PM sends an e-mail to the Dev. Explaining the new task. As he has sent the e-mail, the PM assumes that the message reached the destination and moreover as he has not received any answer, assumes that the Dev. understood the task.
What could happen in this example is that the e-mail never reached the Dev. And so the task was not performed creating an unnecessary trouble to the team.

This is just one of the examples we can give just to show the troubles of not understanding the roles in a communication. This kind of trouble can be enveloped in the “System Communication” category, because it just refers to the system issue (not taking serious the roles during a communication).

To solve this kind of issues we just have to understand our role in the communication: in this case the sender must always assure that the message reached the destination.

Communication failure: Mental models

Now we will go one step further, taking into account that communication is done between people and they have internalized a mental model and they belong to a geographical zone with their own culture.

What do you see here?

Note: This picture was extracted from Miguel’s presentation

For occidental people this picture may illustrate 2 persons in a room with a window, whereas for people who live in Africa it may illustrate 2 persons; 1 carrying a package; and a palm behind them.

Using this example we can say that every person has mental model which is composed by the culture, by his experiences, etc. By this mental model the person see the world and the reality (his reality).

Now is not enough that sender assures that the message reached the destination, he has also to be sure that the message was clearly understood by the receiver.

Communication failure: Requests at projects

Now we will deepen the communication issues by analyzing how requests are done during a project.

Have you ever received an e-mail being asked to do something urgent?
I have. But what is urgent? When should the task be finished?

I think this is one of the most important issues we have in communication during a project: people tend to do vague requests.

To solve this kind of issue I propose the following guideline and rules:

1. The content of the message must be clearly defined: What do you need.
2. Do not be vague: Use the correct verb (I want instead of I would like).
3. Specify the deadline of the request: By when do you need it (do not use urgent as a deadline).
4. Specify who must accomplish the request.

Communication failure: Commitments at projects

How many times you committed to perform tasks that you were unable to accomplish?
I did it lots of times digging my own thumb: loosing the trust of my customers.

We should be very careful with the commitments we do because it may hardly damage our image. We should take into account:

• All commitments are free and volunteer.
• We can delegate actions but not responsibilities: we are always responsible for our commitments.
• Our integrity is going to be evaluated.

Note: This picture was extracted from Miguel’s presentation

Commitments are tightly related to the way we manage expectations, so I recommend you to read my post about expectations management

Final conclusion

Project failure is affected by lots of factors and causes. One of them is intrinsic to the way we communicate and the troubles we have doing so. This post tries to expose some of the most common issues that appear during a project when people communicate. By following the written guidelines and proposed solutions we can control and reduce the probability of project failure.

Of course there is a lot more stuff to do, but we have to start with something and why not starting to communicate better messages?

The congress

On November the 7^th I had the pleasure to attend to the first Project Management congress organized in Argentina. It took place in Buenos Aires at the Sheraton hotel.

During the congress there were 5 speeches about different subjects related to how we manage projects nowadays.

The speeches

The first speech was given by Miguel Bilello and the subject was “The communication during a project”. During his speech Miguel talked about the causes and factors of projects failure; misunderstandings during a project due to the lack or bad communication; the assimilated mental models that people have internalized and how they affect the message transmitted in a communication; the way we ask for requests and the way we take commitments that later we cannot accomplish.

Fernando Garcés, PMP, was in charge of the second speech which subject was “Strategic Business Management Project”. During his speech, Fernando talked about the way the project management is done at the highest level of a company and its main issues.

The third speech was given by Adrián Muiño, PMP, and the subject was “Gates to success”. Adrian explained what this new project management methodology is about, its advantages y how can be implemented in a company.

Sergio Apfelbaum, PMP, was in charge of the forth speech which subject was “The process of certificating PMP”. During his speech, Sergio talked about what this certification consists on; which are its benefits; the necessary pre-requisites to apply for the certification; and how the process of certification is after having applied for it.

The fifth and last speech was given by Marcelo Granieri, PMP, and the subject was “OPM3 (Organizational Project Management Maturity Model)” which is a model that measures the maturity of a company to manage projects. Marcelo talked about the concepts of OPM3, the advantages and benefits of the model.

Conclusion

I can say that the balance of the congress was highly positive considering the themes and the dynamic of the speeches. The subjects of all the speeches were very interesting taking into account the fact that we deal with them in our every day work at the office. The dynamic of the speeches was also very good because, they were short and precise leaving 10 minutes at the end of the speech for a Q&A.

During the next days I will be writing more articles in my blog to deepen these themes treated in the congress.

A problem: Project Failure

Sometimes we feel disappointed because the project we have been working for a while has failed. We think we did as much as possible and that there was nothing left to do.
We spent days and nights working hard, but after all that effort we find we haven’t reached the clients expectations and everything we have done was in vain. 

A possible cause: Setting unreal expectations

Recently I have been thinking that one possible reason of project failures may be that expectations are not correctly set at the beginning of the project. People tend to commit to more than they are able to, setting unreal o high expectations to their clients.  Once expectations are set, your clients plan accordingly on their part. They plan other internal projects around your specific deadline; create strategies that are dependent on your deliverables, etc.
Your client has a much bigger plate than just your work.

Usually the power of expectation is beneficial; other times it can put us into a painful realm where no one can live happily. This is the place of unrealistic expectations—the ones we put on ourselves as well as the ones others place on us.
Expectations must always square reality.

When expectations are not well managed, sooner or later something blows, crisis take control of the situation and the project budget is finally cut off.

A practical approach: Using some tools

Expectations should be based on project features estimations. Our experience tells us they are not always very accurate,  we have to consider estimations margin errors when we set customers expectations.  

In Southworks we have several tools to keep clients expectations accordingly with what we are able to do.
We use a “Backlog” where we list all customers’ requirements. We keep this backlog up to date, adding new requirements appropriately, deleting dropped requirements, etc.
We periodically show the “Backlog” to the customers so their expectations are up to date with the project requirements and estimations. As the project moves on, estimations improve and its margin error diminishes.

We also use a similar tool to work internally. Developers can decide and choose their daily tasks. They estimate and decide how many tasks they are going to do each day. This means they can manage their “Project Manager” expectations by only committing to what they think they are able to. In other words, working this way they have the chance to do what is called “under promise” and “over deliver”.

Conclusion

Managing customer expectatives is not an easy job; it requires estimation skills and experience on dealing with customers.
Luckily there are some tools that may help us with this difficult task such as the “Backlog”.

To close this article I would like to share with you some mindsets related with expectation management that have been useful for me:

• Your client has a much bigger plate than just your work.
• Under promise, over deliver.
• Expectations must always square reality.
• Keep the customer on track, up to date with project latest news.

Related Links:

• ttp://prblog.typepad.com/strategic_public_relation/2002/10/expectation_man.html
• http://ctlibrary.com/6119
• http://gruntdoc.com/2007/06/expectations-or-letting-people-down.html
• http://aaronstewart.blogspot.com/2007/04/i-have-often-talked-with-people-that_01.html

Introduction

Sometimes emotions and feelings interfere when working with other people. In some occasions we think that being professionals is to avoiding those feelings instead of handling them. As they may affect our work and performance a good way to take care of the situation is to share and discuss them directly. Having “One on One” disussions gives us a chance to do so.

Having a one on one meeting

Two co-workers get together in a room to freely argue about a specific issue that is affecting their work relationship. The aim of these kind of meetings is to solve the issue as soon as possible and to keep a healthy relationship between co-workers.
Most people have a better performance if they carry out their work in a healthy environment, where they can happily interact.

2 co-workers having a one on one discussion to solve their issues.

For example this kind of meetings are often useful when a subordinate disagree in an issue with his manager and fears to tell him; even when he disagrees or gets upset with some of his attitudes.
In this case the subordinate could arrange to have a “One on One discussion” to freely communicate his thoughts and achieve an agreement with his manager without fearing to get fired.

result of “one on one” discussion: the 2 co-workers could solve their issues and got an agreement.

Rules

There are a couple of conventions:

• Two persons meet in a room, with nobody else, to argue and discuss an specific issue.
• Everything that is said during the meeting must keep inside the room.
• It does not matter which is the relationship that connects these two persons; not even their roles or responsibilities inside an organization, the familiar bow, etc.

Scenario:

In Southworks, we had to migrate workitems of some tfs projects from one server (let’s call it “Server A”) to another (let’s call it “Server B”).

“Server A” was Team Foundation Server RC version and “Server B” was Team Foundation Server RTM, so that’s one of the factors that made us not follow the steps of How to: Move Your Team Foundation Server from One Hardware Configuration to Another.

The other one was that in “Server B”, we had some projects that already existed in “Server A” , and we did not want to loose the existing workitems of these projects in the migration process.

To summarize , what we had to do was to merge projects of “Server A” and “Server B” into “Server B”.

Solution:

We created an application that uses the TFS API and performs the following steps:

1. Connect to “Server A”.
2. Connect to “Server B”.
3. Migrate workitems from “Server A” to “Server B”.
   1. Get all workitems from one project in “Server A”.
   2. Insert all selected workitems into the corresponding project in “Server B” (This includes inserting workitems attachments).
   3. Insert all new workitems in “Server B” links.

Click here to download the sample.

Conclusion:

The most interesting thing you can get from this application is that using the TFS API you can do complex transformations to the projects and workitems of Team Foundation Servers.
You can:

1. Edit workitems fields.
   1. Insert links.
   2. Add attachments.
   3. Etc.
2. Copy workitems from one project to another (or from 1 server to another server, as we did).
3. Merge projects workitems.
4. Etc.

There is much more to research about the TFS API.
It is a powerful tool and I think this sample is a good starting point to understand how TFS API works and what you can do with it.

In this post I will show the different ways of saving state on the server.
Below I describe these different ways.

• In Proc:
  Is default mode that is enabled in ASP NET. It saves session in the server memory.
  
• State Server Mode:
  The session state is saved in separate process, called ASP NET state service.
  This allows, session to be preserved if the web application is restarted.
  Moreover session state is available to multiple web servers in a web farm.
  
• Sql Server Mode:
  The session state is saved in Microsoft  Sql server database.
  This allows, session to be preserved if the web application is restarted.
  Moreover session state is available to multiple web servers in a web farm.
  
• Custom Mode:
  This mode allows you to specify a session state storage provider.
  In other words, you can decide to save session wherever you want.

In this post I will try to explain the different ways of state saving information in web applications.
I will write a brief description about them, trying to give an global idea of the several options of saving state information in Web Applications.

Scenario
Every post the browser sends to the server a new instance of the page is created loosing all the information added in the client side.
This happens because in every roundtrip the server disposes the old aspx page and creates a new instance of it, sending back to the browser this new created page. 

Solutions
There are several ways for solving the situation mentioned above.
These possibilities are categorized it two different branches as follows.

• Client - Based State Management Options
  By using this way, the information is not stored on the server between roundtrips.
  • View State:
    This is the default method that the page uses to preserve page and control data between roundtrips.
    When the page is processed on the server, the current state of the page and the controls are hashed into a string and saved in the page
    as a hidden field or multiple hidden fields, depending on the amount of data stored exceeds the value of the System.Web.UI.Page.MaxPageStateFieldLength property.
    When the page is posted back to the server, the page parses the viewstate string at page initialization and restores the page and controls properties.
    If you are looking for examples of using View State click here.
  • Control State:
    Sometimes you need to store information of a control so it can work properly. For example let’s suppose you have written a custom control that has different tabs that show different information, the control needs to know which tab is selected to work as expected.
    The view state could be a good option for solving this need, but it can be tuned off at page level by developers, breaking your control.
    For solving this problem ASP NET exposes a new feature called Control State.
    This feature is useful when you want to store information that is specific to the control.
    For persist this information you can use System.Web.UI.PageStatePersist.ControlState. This property cannot be turned off.
  • Hidden Form Fields:
    ASP NET allows you to use html standard hidden fields in a form. A Hidden Field is not visible to the users, but you can set ir properties just as a control.
    When a page is submitted the Hidden Field is sent in the http form collection with the other control’s values.
    A Hidden Field can store a single variable in its value property and it must be explicit added to the page. To insert values into a hidden field ASP NET provides the System.Web.UI.HtmlControls.HtmlInputHidden control which offres hidden-field functionality.
  • Cookies:
    A cookie is a small amount of data that is stored in a text file on the FileSystem or in the memory of the client browser session.
    This cookies can be temporary (defining time and date expiration), or the can be persistent.
    The server can read the cookie and extract it values.
    A typical use is to store a token indicating that the user has already been authenticated in the application.
    The browser can send the data back only to the server that created the cookie. However, malicious users have ways to access cookies and read their contents.
    It is recommended not to store sensitive data such as username and password in a cookie. Instead of these, store a token that identifies whether the user is authenticated and look up this information on the server.
  • Query Strings:
    Is information that is appended to the end of the URL of the page. In the URL path the query string starts with “?”.
    Query Strings provides a simple but limited way of maintaining state information.
    For example, it can be used for sending product number from one page to another where it will be processed.
    Information passed by Query String can be used by malicious users so you have to be very careful while choosing the information you pass.
    For Query String to be available during the page processing you must submit the page by using Http Get Command.

          

• Server - Based State Management
  By using this way, the information is stored on the server and decrease the amount of information sent to the client to preserve state.
  However this approach can use costly resources on the server. 
  • Application State:
    It is a global storage mechanism that is accessible from all the pages in your web application.
    It is useful for storing information that is cross cutting to the entire web site and you don’t want to lose it between roundtrips and request for pages. ASP NET allows you to save values in the Application State by using an instance of the class System.Web.HttpApplicationState.
  • Session State:
    It is similar to Application State except that the information stored is only accessible to the browser that created it.
    If you have different users accessing to your web application, each of them will have it’s own Session to save information.
    None of them can use other Session State.
    ASP NET allows you to save values in the Session State by using an instance of the class System.Web.HttpSessionState.
    This session information can be stored in:
    • Cookies.
    • Out of process server.
    • Microsoft Sql Server.

This is the default method that the page uses to preserve page and control data between roundtrips.
When the page is processed on the server, the current state of the page and the controls are hashed into a string and saved in the page
as a hidden field or multiple hidden fields, depending on the amount of data stored exceeds the value of the System.Web.UI.Page.MaxPageStateFieldLength property.
When the page is posted back to the server, the page parses the viewstate string at page initialization and restores the page and controls properties.

View State provides an easy way to automatically persist field and control data on the page without having to manually request it and re-populate it during roundtrips to the sick right button on the page and select “View Source”

A new window is opened.
Localize the View State inside the window and look how long it is.
Notice that the string is hashed in the property value.

How to turn off View State for a:

• Page: Page.EnableViewState = false;
• Control: ControlXXX.EnableViewState = false;

In both cases, you have to go and write that code in the code behind of the page.

Chunking the View State
When the View State becomes very large as they are stored in hidden fields, some proxies and firewall prevent access to the page that contains them. For this reason ASP NET 2.0 introduces a new feature called View-State Chunking. If the amount of data becomes too large, View-State Chunking will split it into chunks and put the data into multiple hidden-form fields.
To enable View-State Chunking set the System.Web.UI.Page.MaxPageStateFieldLength to the maximum size that you want to allow in a single view-state field. The default value o this property is “-1″, that means that there is no maximum value so that the View State Chunking is not enabled.

How to chunk the View State:
In the source code of the page, add MaxPageStateFieldLength = XXX in the <page> directive at the top of the page.
This will set the maximum amount of data saved in each View State field.
If the View State exceeds the value you set, it will split in chunks.

Between August 14 and August 22 I had the pleasure of attending to a Core Data Access with Microsoft Visual Studio 2005 course.
It consisted in 5 classes, one per week day. 
Every day, Franco Cerutti (the course Teacher) gave us a short speech about what we were going to do afterwards in the Labs.
This Labs were some excersices where we put in practice what Franco has taught us before.
In summary this course, was divided in 2 parts:

                      
Day 1:  Unfornately the class was suspended beacuse the Virtual Pc (VPC) where we do the Labs were not Working properly. 
           We recovered this class on the Day 6, one week later.

Day 2:  We learnt how to:

• Connect to a database, retrieve information from it using ADO. NET.
• Encript the connection string in the web config using RSA.
• Configure and use connection Pooling.

              In this class I Found very interesting how to encript the connection string in the web config using RSA.

Day 3:  In this class we learnt how to:

• Create and run Querys 
• Run Update Commands.
• Run parameterized querys and update commands .
• Transactions:
  • Local Transactions.
  • Distributed Transactions.

            I found very interesting:

• The different ways of working with transactions.
  • Local Transactions.
  • Distributed Transaction
    
• Isolation levels for transactions.
  • Read Commited.
  • Read Uncommited.
  • Repeteable Read.
  • Serializable.

Day 4:  In this class we learnt how to:

• Create Datasets.
• Add, modify and delete Data in a DataSet.
• Work with Views.
• Perform disconnected operations:
  • Loading saving and displaying data in a typed Dataset.
  • Creating a typed dataset by using the data source configuration wizard.

Day 5:  In this class we learnt how to:

• Perform XML operations on Disconnected Data:
  • Saving a DataSet as XML.
  • Loading a DataSet from XML.

            In this class I found very interesting the DiffGram Format for saving DataSet in XML. This format allows you to save the DataSet including:

• The actual data of the DataSet.
• The original version of the DataSet (If you modified de data of the dataset, the previous information is saved).
• The errors of each row of the DataSet.